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PREFACE 


This  document  is  the  revised  MIL-STD-1589B  Draft  (USAF)  definition 
of  the  upgraded  J73  JOVIAL  programming  language.  The  sections  are 
organized  in  a  top- down  manner*  The  first  section  describes  the 
interactions  between  the  modules  of  the  complete  program  so  that  in 
subsequent  sections  the  structures  of  the  language  can  be  described  (to 
the  extent  possible)  without  reference  to  their  interaction  with  other 
structures. 

Host  sections  are  divided  into  separate  parts  entitled  '’Syntax," 
''Semantics,'*  and  ''Constraints.1*  The  "Syntax1*  descriptions  define  the 
grammar  of  the  language  in  a  modified  BNF  notation.  The  '’Semantics'* 
discussions  define  the  meaning  of  constructs  that  satisfy  the  Syntax  and 
Constraints.  The  ''Constraints'*  discussions  enumerate  non-syntactie 
requirements  that  must  be  met  in  order  for  the  given  constructs  to  be 
legal.  The  intent  is  that  the  Syntax,  Semantics,  and  Constraints  not  be 
redundant  with  each  other  -  e.g.,  the  Semantics  sections  do  not  normally 
repeat  something  that  shotild  be  obvious  from  the  Syntax,  neither  do  they 
repeat  stipulations  that  are  listed  as  Constraints. 

Some  of  the  designated  Constraints  apply  at  compile  time,  and 
others  pertain  to  errors  that  are  not  detectable  until  the  compiled 
program  is  executed.  In  order  to  conform  to  this  standard,  a  J73 
compiler  must  detect  compile-tlme  errors,  but  it  is  not  required  to 
generate  code  for  run-time  checks. 

V* 

The  Appendix  provides  a  cross-reference  index  to  constructs  that 
appear  in  the  Syntax.  For  each  construct,  the  index  gives  the  number  of 
Che  section  where  that  construct  is  defined  and  the  numbers  of  the 
sections  where  that  construct  is  used  in  a  definlton. 

The  following  metalanguage  conventions  have  been  observed  in  this 
document : 

1.  Terminal  symbols,  i.e.,  chose  which  actually  appear  in  a 
program  are  written  in  upper  case.  For  example: 

BEGIN 

END 

STATIC 

2.  Non-terminal  symbols,  i.e.,  those  which  represent  groups  of 
terminal  symbols  are  written  in  lower  case  and  enclosed 
between  <  and  >.  If  any  non-terminal  symbol  is  longer  than 

_  _ _ one  word,  the  words  are  separated  by  a  hyphen.  For  example: 


o  i: 

>  *  :■ ) 
c-.  r,  j 

&  p  *•> 


in 


i 
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<compool-module> 

<ordinary-table-body> 

3.  The  following  special  symbols  are  used  in  the  metalanguage. 

means  "is  defined  as."  For  example, 

<a>  <b>  <c> 

where  <a>  is  defined  as  the  string  <b>  followed  by 
the  string  <c>.  Definitions  that  do  not  fit  on  one 
line  may  extend  to  the  next  line  or  lines. 

I  The  |  symbol  indicates  that  what  follows  is  an 
alternate  choice  of  definition  for  the  non-terminal 
to  the  left  of  the  symbol.  For  example, 

<a>  ::-  <b>  |  <c> 

where  <a>  is  defined  as  either  the  string  <b>  or 
the  string  <c>. 

I  J  If  a  string  may  optionally  be  present,  it  is 
enclosed  between  [  and  ] .  For  example, 

<a>  l<b>]  <c> 

where  <a>  is  defined  as  either  the  string  <c>  or 
the  string  <b>  followed  by  the  string  <c>. 

4.  The  following  symbols  have  metalinguistic  meaning  when 
appended  to  a  non-terminal: 

...  One  or  more  Instances  of  the  string  represented  by 
non-terminal 

,...  One  or  more  instances  separated  by  a  comma 
:...  One  or  more  instances  separated  by  a  colon 
For  example: 

<a>...  Represents  a  single  <a>  or  any  sequence  of  <a>'s 
(e.g.,  <a>  or  <a>  <a>  or  <a>  <a>  <a>  <a>  etc.) 

[<a>...]  Represents  the  null  string  or  any  sequence  of  <a>'s 

<a>,...  Represents  a  single  <a>  or  any  length  sequence  of 

<a>'s  separated  by  commas  (e.g.,  <a>  or  <a>,<a>  or 


* 
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<a>,<a>,<a>  etc.) 

5.  If  a  non-terminal  appearing  on  the  right  side  of  the  : :■  is 

not  defined  in  that  same  sub-section,  the  number  of  the 

sub-section  where  it  is  defined  appears  in  parentheses  in  the 
right  margin. 

6.  In  a  "Semantics"  or  "Constraints"  section,  non-terminal 

symbols  are  enclosed  between  <  and  >  when  the  usage  refers  to 
constructs  occurring  in  a  "syntax"  section  or  when  the 
specific  J73  meaning  might  be  confused  with  generalized 
programming  usage. 

Throughout  this  document,  the  symbols  used  for  the  prime,  the 
quotation  mark,  and  a  blank  are  as  follows: 

1 .  Prime 

2*  Quotation  mark  " 

3 .  Blank  space 
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1.0  GLOBAL  CONCEPTS 
1.1  THE  COMPLETE  PROGRAM 


Syntax: 


<comple t e-progr  an> 


<module> . . . 


<nodule> 


Semantics: 


■  <compool-module> 

J  <procedure-module> 

I  <main-program-module> 


(1.2.1) 

(1.2.2) 

(1.2.3) 


A  <cooplete-program>  of  the  J73  language  gives  the  complete 
specification  of  a  computational  algorithm  to  be  performed.  A 
<complete-program>  consists  of  a  group  of  one  or  more  <modules>  that  are 
compilable  separately  and  which  may  be  subsequently  bound  together  for 
execution  as  a  unit.  A  <module>  is  the  smallest  entity  in  the  language 
that  may  be  separately  compiled. 


A  <complete— program>  may  contain  zero  or  more  <compool-modules>  and 
zero  or  more  <procedure-modules>. 

Constraint: 


A  <complete-program>  must  contain  exactly  one  <main-program- 
module> . 

Note: 


A  compiler  may  accept  a  file  containing  more  than  one  <module>,  but 
it  is  not  required  to  do  so.  If  it  does  accept  such  a  file,  it  must 
process  each  <module>  as  though  it  had  been  submitted  separately. 


1 .2  MODULES 

1.2.1  C0MP00L  MODULES 

Syntax: 

<compool-module>  START  [<directive>. . .]  (9.0) 

C0MP00L  <compool-name>  ; 
(<compool-declaration>. . .]  (2.0) 

[<dlrective>. . .]  (9.0) 

TERM 
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<compool-name>  <name>  (8.2.1) 
Semantics : 

<Compool-modules>  provide  a  means  of  declaring  data  objects,  types, 
and  subroutines  that  are  to  be  made  external  -  i.e.,  that  are 
potentially  available  to  other  <modules>  In  the  <complete-program>. 
Another  <module>  may  access  the  names  declared  In  a  given 
<compool~raodule>  by  use  of  a  <compool-directive>  (see  Section  9.1)  that 
names  the  given  compool  or  by  use  of  external  declarations  (see  Section 
2.5). 


A  <compool-module>  may  contain  <compool-directives>  that  nane  other 
<compool-modules> . 

By  appropriate  use  of  <def-specificatlons>  and  <ref-speclflcatlons> 
within  <compool-~declaratlons>,  a  user  can  control  whether  physical 
allocation  takes  place  within  the  <compool-module>  Itself  or  within  the 
accessing  <module>  (see  Section  2.5). 


1.2.2  PROCEDURE  MODULES 


Syntax: 


<  pr ocedure-module> 

: :«  START 

(2.0) 

[<declaration>. ..] 
[<non-nested-subroutine> . . . ] 

[<directive>.;.] 

(9.0) 

TERM 

<non-nested-subroutine 

: [<directive> . .] 

(9.0) 

[DEF]  <subroutine-definition> 

(3.0) 

Semantics: 

<Procedure-modules>  provide  a  means  of  separately  compiling 
subroutines  that  specify  portions  of  the  actions  of  the  <complete— 
program> . 


If  a  <subroutlne-def initlon>  is  preceded  by  DEF,  that  subroutine 
may  be  invoked  from  within  the  <main-program-module>  or  from  within 
another  <procedure-module> ,  provided  that  the  referencing  module 
contains  an  appropriate  <ref-specification>  for  the  subroutine  or 
accesses  a  compool  containing  such  a  specification. 


<Non-nested-subroutines>  defined  without  a  DEF  may  be  invoked  only 
from  within  the  <procedure-module>  or  <main-program~module>  in  which 


2 


« 


1  I 
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they  are  defined.  Similarly,  all  declarations  in  a  <procedure-module> 
apply  only  within  that  <procedure-module>  (unless  they  are 
<exteraal-dedarations>  -  see  Section  2.5). 


1.2.3  MAIN  PROGRAM  MODULES 


Syntax: 

<main-program-module> 


<program-name> 

<program-body> 


START  [<dlrective>'..] 

(9.0) 

PROGRAM 

<program-name>  ; 

[<directive> . . .] 

(9.0) 

<program-body> 

[ <non-nes ted-subroutine> . . . ] 

(1.2.2) 

[<directive>. ..] 

(9.0) 

TERM 

<name> 

(8.2.1) 

<statement> 

(4.0) 

BEGIN  [ <declaratlon> . . . ] 

(2.0) 

<statement>. . . 

(4.0) 

[<subroutine-definition>. . .] 

(3.0) 

[<directive>. . .] 

(9.0) 

[<label> . . . ]  END 

(4.0) 

Semantics : 


The  body  of  a  <main-program-module>  is  executed  at  the  start  of  a 
<complete-program>.  When  execution  of  the  body  is  complete,  execution 
of  the  <complete~*program>  is  complete.  Unless  the  <complete-program> 
consists  of  a  single  <main-program-module> ,  the  <main-program-module> 
will  contain  one  or  more  <compool-directives>,  references  to 
externally~declared  data,  and/or  calls  of  DEF'd  subroutines  in  other 
modules. 


Declarations  in  a  <main-program-module>  may  be  external  or 
internal.  If  a  <non-nested-subroutine>  has  a  DEF,  it  may  be  invoked 
either  locally  or  from  within  a  <procedure-module> ,  provided  that  the 
referencing  module  contains  an  appropriate  <ref-specif ication>  for  the 
subroutine  or  accesses  a  compool  containing  such  a  specification.  If  it 
does  not  have  a  DEF,  it  can  be  invoked  only  from  within  the  module  in 
which  it  is  defined. 
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Constraints: 

The  <program-body>  must  contain  at  leaat  one  non-null  statement 
(e.g.,  STOP). 


1 .2 .4  CONDITIONAL  COMPILATION 

Two  methods  are  provided  for  conditionally  suppressing  generation 
of  object  code  for  portions  of  a  JOVIAL  module. 

The  !SKIP,  IBEGIN,  and  !END  directives  (see  Section  9.2.2)  permit 
almost  complete  suppression  of  processing  of  suppressed  source.  The 
only  processing  done  for  suppressed  source  is  to  scan  for  the 
terminating  !END  directive.  Therefore  the  suppressed  source  may  contain 
errors  and/or  statements  incompatible  with  other  module  source  without 
affecting  compilation. 

The  IF  and  CASE  statements  (see  Sections  4.3  and  4.4)  permit 
suppression  of  generation  of  object  code.  Source  for  this  suppressed 
object  code  must  be  correct  since  it  is  subject  to  the  same  validity 
checks  and  processing  of  directives  as  other  source  code.  Only  code 
that  is  unconditionally  unreachable  is  suppressed  so  this  conditional 
compilation  must  produce  the  same  results  as  if  the  code  was  generated. 
Segments  of  code  which  are  unreachable  due  to  values  of  <if-statement> 
<boolean-formulas>  or  <case-selector-formulas>  which  are 
<compile-time-formulas>  and  which  do  not  contain  <labels>  are  always 
suppressed.  Implementations  may  choose  to  do  a  more  complete  analysis 
and  also  suppress  other  recognized  unreachable  code. 


1.3  SCOPE  OF  NAMES 

<Frocedure-modules>  and  the  <main-program-module>  can  contain 
subroutines  (i.e.t  procedures  and  functions)  nested  to  any  depth.  Each 
subroutine,  as  well  as  the  <program-body>  and  the  <main-program-module> 
or  <procedure-module>  itself,  establishes  a  region  or  scope  for  which  a 
name's  declaration  is  active  and  in  which  the  <name>  can  be  used.  The 
scope  of  a  <name>  is  that  region  of  the  <complete-program>  within  which 
that  <name>  has  a  single  meaning. 

A  name  declared  with  a  DEF  or  REF  (see  Section  2.5)  is  considered 
to  be  external;  all  other  names  are  internal.  An  external  <name>  can  be 
used  in  any  module  of  the  <complete-program> ,  except  within  a  scope 
containing  an  internal  name  with  the  same  spelling.  An  internal  name 
can  be  used  only  within  the  subroutine,  <procedure-module>,  or 
<maln-program-module>  within  which  that  name  is  declared,  but  not  within 
an  enclosed  scope  containing  a  <name>  with  the  same  spelling. 
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The  <name>  of  a  subroutine  belongs  to  the  scope  in  which  that 
subroutine  is  declared  or  defined. 

For  any  given  compilation,  all  names  made  available  from  referenced 
<compool-modules>  (see  Section  9.1),  as  well  as  the  name  of  the  <module> 
being  compiled  and  all  <compool-namea>,  belong  to  the  same  scope, 
referred  to  as  com pool  scope,  which  is  considered  to  enclose  the  scope 
established  by  the  <procedure-module>,  <main-program-module>,  or 
<compool-module>  being  compiled. 

System-defined  names  (e.g.,  machine-specific  subroutines, 
implementation  parameters)  belong  to  system  scope,  which  encloses  the 
compool  scope.  Such  names  may  be  redefined  by  the  programmer. 

These  rules  ensure  that  any  two  names  with  the  same  spelling  but 
with  distinct  scopes  are  regarded  as  if  they  were  different  names. 

Constraints: 

No  two  names  having  the  same  scope  may  have  the  same  spelling. 
(This  .constraint  does  not  prevent  two  tables  with  different 
<table-names>  to  be  declared  in  the  same  scope  using  the  same 
<table-type-name> .  See  Sections  2.1.2  and  2.2.) 

No  two  external  names  may  have  the  same  spelling. 


1 .4  IMPLEMENTATION  PARAMETERS 
Syntax: 

<integer-machine- 

parameter>  : :*  B1TSINBYTE 

I  BITSINWORD 

I  LOCSINWORD 

i  BYTEPOS 

(  <compile-time-integer-formula>  )  (5.1.1) 

|  BYTES INWORD 
I  BITSINPOINTER 
I  INTPRECISION 


I  FLOATPRECISION 
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|  FIXEDPRECISION 
|  FLOATRADIX 
I  IMPLFLOATPRECISION 

(  <precision>  )  (2. 1.1. 2) 

I  IMPLFIXEDPRECISION 

(  <scale-specifier>  ,  (2. 1.1. 3) 

<f raction-specif ier  )  (2.1 .1.3) 

I  IMPLINTSIZE 

(  <integer-size>  )  (2. 1.1.1) 

|  MAXFLOATPRECISION 
|  MAXFIXEDPRECISION 
|  MAXINTSIZE 

|  MAX BYTES  * 

|  MAXBITS 

I  MAXINT  (  <Integer-size>  )  (2. 1.1.1) 

I  MININT  (  <lnteger-size>  )  (2. 1.1.1) 

I  MAXTABLESIZE 
|  MAXSTOP 
|  MINSTOP 
|  MAXSIGDIGITS 
|  MZNSIZE  ( 

<compile-time-integer-formula>  )  (5.1.1) 

|  MINFRACTION  ( 

<compile-tiae-floating-fonaula>  )  (5.1.2) 

|  MINSCALE  ( 

<compile-time-floating-formula>  )  (5.1.2) 

|  MINRELPRECI SION  ( 

<compile-time-floating-foroula  )  (5.1.2) 
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<f loa  c 1 ng-mach in* 
parameter> 


<f ixed-machine- 
parameter> 
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MAXFLOAT  (  <precision>  )  (2.1.1 .2) 

I  MINFLOAT  (  <preciaion>  )  (2. 1.1. 2) 

I  FLOATRELPRECISION 

(  <precislon>  )  (2. 1.1. 2) 

I  FLOATUNDERFLOW 

(  <preclslon>  )  (2. 1.1. 2) 


MAXFIXED  (  <scale-specifier>  ,  (2. 1.1. 3) 

<fraction-speclfier>  )  (2. 1.1. 3) 

MINFIXED  (  <scale-specif ier>  ,  (2. 1.1. 3) 
<fraction-specifier>  )  (2. 1.1. 3) 


Semantics: 


The  machine  on  which  a  J73  program  runs  contains  an  array  of  memory 
cells.  These  cells  are  grouped  or  partitioned  into  the  following  units 
for  purposes  of  the  language  specification. 

1.  Bit  -  The  smallest  unit  of  storage  (can  contain  one  of  two 
values ,  which  are  represented  by  zero  and  one) 

2.  Byte  -  A  group  of  one  or  more  consecutive  bits  that  is  capable 
of  holding  a  single  character  of  information 

3.  Word  -  A  memory  partition  of  one  or  more  consecutive  bits  chat 
serves  as  the  unit  of  allocation  of  data  storage 

4.  Address  Unit  -  The  machine  dependent  unit  used  to  identify  an 
address  or  location  in  memory 

The  number  of  bits  per  byte,  word,  and  address  varies  from 
implementation  to  implementation,  and  these  quantities  affect  the 
representation  and  behavior  of  data  in  the  language.  Machine  parameters 
are  constants  that  describe  these  implementation-dependent  differences. 
The  values  of  these  constants  must  be  specified  as  part  of  the 
implementation  of  a  J73  compiler  on  any  computer.  These  names  can  then 
be  referenced  by  a  user  to  access  the  values  associated  with  that 
implementation. 

The  size  of  an  <integer-machine-parameter>  is  the  size  of  an 
<integer-literal>  having  that  value.  The  attributes  of  a  <floating- 
machine-parameter>  or  <f lxed-machine-parameter>  are  as  specified  by  its 
<precision>  or  its  <scale-specifier>  and  <fraction-specifier>.  The 
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values  of  che  implementation  parameters  are  as  follows: 


B1TSINBYTE 

Number  of  bits  in  a  byte 

BITSINWORD 

Number  of  bits  in  a  word 

LOCSINWORD 

Number  of  locations  (address  units) 
in  a  word 

BYTEPOS(PP) 

A  permitted  <starting-bit>  value  for 
character  strings  that  cross  word 
boundaries.  PP  is  any  integer  value 
between  0  and  BYTESINWORD- 1 , 
inclusive  and  BYTEPOS(PP)  < 
BYTEP0S( PP+1 ) . 

BYTESINWORD 

Number  of  complete  bytes  in  a  word 

BITSINPOINTER 

Number  of  bits  used  for  a  pointer 
value 

INTPRECISION 

The  number  of  bits  that  an 
implementation  supplies  to  hold  the 
value  of  an  integer  item  (exclusive 
of  sign,  if  any)  when  no 
<integer~8ize>  is  specified  by  the 
programmer. 

FLOATPRECISION 

The  number  of  bits  chat  an 
implementation  supplies  to  hold  the 
value  of  the  mantissa  of  a  floating 
point  item  (exclusive  of  the  sign 
bit)  when  no  <precision>  is  specified 
by  the  programmer 

FIXEDPRECISION 

The  number  of  bits  that  an 
implementation  supplies  to  hold  the 
value  of  a  fixed  item  (exclusive  of 
the  sign  bit)  when  no  <fractiou- 
specifier>  is  supplied  by  the 
programmer 

FLOATRADIX 

Base  of  the  floating  point 
representation,  specified  as  an 
integer 

IMPLFL0ATPRECISI0N( II) 


Number  of  bits  (not  including  the 
sign  bit)  in  the  mantissa  of  the 
representation  for  a  floating  point 
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value  whose  specified  precision  Is  II 

IMPLFIXEDPRECISION(SS,FF)  The  number  of  bits  (excluding  sign 

bit)  an  implementation  uses  to 
represent  an  unpacked  fixed  item  with 
scale  SS  and  fraction  FF.  This  value 
also  determines  the  accuracy  of  fixed 
formula  results. 


IMPLINTSIZE(II) 


MAXFLOATPRECISION 


MAXFIXEDPRECI SION 


MAXINTSIZE 


MAXBYTES 


MAXBITS 


MAXINT(SS) 

MININT(SS) 


The  number  of  bits  (excluding  sign 
bit)  an  implementation  uses  to 
represent  an  unpacked  S  or  U  item 
with  specified  size  II. 

Maximum  specifiable  precision 
supported  by  an  implementation  for  a 
<floating-item-description> 

Maximum  value  supported  by  an 
implementation  for  the  sum  of  the 
scale  and  fraction  specifiers  in  a 
<fixed-itenr-description> 

Maximum  specifiable  size  (not 
including  the  sign  bit)  supported  by 
an  implementation  for  signed  and 
unsigned  integers 

Maximum  value  supported  by  an 
implementation  for  a 
<character-size>;  must  not  exceed 
MAXBITS/BITSINBYTE 

Maximum  value  supported  by  an 
implementation  for  a  <bit-size>;  the 
maximum  value  of  words  per  entry  in  a 
table  is  MAXBITS/ BITSINWORD,  and  the 
maximum  BITSIZE  of  a  table  entry  is 
MAXBITS 

Maximum  integer  value  representable 
in  SS+1  bits  (including  sign  bit) 

Minimum  signed  integer  value 
representable  in  SS+1  bits  (including 
sign  bit),  using  the  implementation's 
method  of  representing  negative 
numbers 
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MAXTABLESIZE 


MAXSTOP 


MINSTOP 


MAXSIGDIGITS 


MINSIZE(II) 


MINFRACTION(AA) 


MINSCALE(AA) 


MINRELPREC IS ION( FF ) 


MAXFLOAT(PP) 


MINFLOAT(PP) 


The  maximum  number  of  words  an 

implementation  permit*  a  table  to 
occupy. 

Maximum  specifiable  value  for  an 

<lnteger-formula>  in  a  <stop- 

statement>  (see  Section  4.9) 

Minimum  specifiable  value  for  an 

<integer-formula>  in  a  <stop- 

statement>  (see  Section  4.9) 

The  maximum  number  of  significant 
digits  an  implementation  will  process 
for  a  fixed  or  floating  point  literal 
(see  Section  8.3.1) 

The  minimum  value  of  SS  such  that  II 
is  less  than  or  equal  to  MAXINT(SS) 
and  greater  than  or  equal  to 

MININT(SS) 

The  minimum  value  of  FF  such  that 
2**(-FF)  is  less  than  or  equal  to  AA. 
The  value  of  AA  must  be  greater  than 
aero. 

The  minimum  value  of  SS  such  that 
2**SS  is  greater  than  AA.  The  value 
of  AA  must  be  greater  than  aero. 

The  minimum  value  of  PP  such  that 
FLOATRELPRECISION(PP)  is  less  than  or 
equal  to  FF.  The  value  of  FF  must  be 
greater  than  or  equal  to 
FLOATRELPRECISION 
(MAXFLOATPJRECISION) . 

Maximum  floating  point  value  using 
only  the  first  PP  mantissa  bits 
(excluding  sign)  of  the 

implementation's  floating  point 
representation  whose  actual  mantissa 
length  is  IMPLFLOATPRECISION(PP) .  PP 
must  be  greater  than  zero  and  not 
exceed  MAXFLOATPRECISION. 

Minimum  floating  point  value 
representable  in  exactly  PP  mantissa 
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FLOATRELPRECI SI0N( PP) 


FLOATUNDERFLOW ( PP ) 


MAXFIXED(SS.FF) 
MINFIXED( SS ,FF) 


bits,  (excluding  sign)  and  using  Che 
Implementation's  method  of 
representing  negative  numbers.  PP 
must  be  greater  than  zero  and  not 
exceed  MAXFLOATPRECI SION. 

Let  FRP1  be  the  smallest  floating 
point  value  greater  than  1 .0  using 
the  first  PP  bits  (excluding  sign)  of 
the  implementation's  representation 
for  floating  point  values. 
FLOATRELPRECISION(PP)  equals  FRP1  - 
1.0.  PP  must  be  greater  than  zero 
and  not  exceed  MAXFLOATPRECI SION. 

The  smallest  positive  floating  point 
value  using  exactly  PP  mantissa  bits 
(excluding  sign)  and  such  that  both 
FLOATUNDERFLOW(PP)  and 
-FLOATUNDERFLOW(PP)  are  representable 
as  floating  point  values 

Maximum  fixed  value  representable  in 
SS+FF+1  bits  (including  sign  bit) 

Minimum  fixed  value  representable  in 
SSWFF+1  bits  (Including  sign  bit), 
using  the  implementation's  method  for 
representing  negative  values 


Note: 


A  FIXED RAD IX  Implementation  parameter  is  not  provided  since  fixed 
point  values  are  represented  using  radix  2  (see  Section  2. 1.1. 3). 
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2.0  DECLARATIONS 
Syntax: 

<d«claration> 

<compool-declaration>  : 


Semantic a: 

<Declaratlons>  associate 


<data-declaration>  (2.1) 

<type-declaratlon>  (2.2) 

<subroutlne-declaration>  (3.0) 

<statement-name-declaratlon>  (2.3) 

<deflne-declaratlon>  (2.4) 

<external-declaration>  (2.5) 

<overlay-declaration>  (2.6) 

<inllne-declaration>  (3.4) 

<null-declaration>  (2.7) 

BEGIN  <declaratlon> . . . 

END 

<directive>  <deciaration>  (9.0) 

<extemal-declaration>  (2.5) 

<constant-declaratlon>  (2.1.3) 

<type-declaratlon>  (2.2) 

<def ine-declaration>  (2.4) 

<overlay-declaration>  (2.6) 

<null-declaratlon>  (2.7) 

BEGIN  <compool-declaration>... 

END 

<dlrective>  (9.0) 

<compool-declaration> 


<names>  with  programme resupplied  meanings. 
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A  <compool-declaration>  is  a  <declaration>  Chat  appears  in  a 
<compool-module> . 

Constraints 


Except  for  <statement-names> ,  names  of  subroutines,  type  names  in 
<polnter-ltem-deserlptions>,  and  formal  parameter  names,  a  name  may  not 
be  used  prior  to  Che  point  at  which  a  <declaration>  for  that  name 
appears. 

9 

2.1  DATA  DECLARATIONS 


Syntax; 


<da  ta-decla  rat ion> 

: :■  <ltem-declaratlon> 

(2.1.1) 

|  <table-declaration> 

(2.1.2) 

I  <constant-declaration> 

(2.1.3) 

I  <block-declaratlon> 

(2.1.4) 

Semantics: 

<Data-declaratlons>  declare  <data-names>  and  their 
Three  kinds  of  data  structures  exist  in  J73: 

attributes 

1.  Item  -  A  simple  data  object  of  the  language.  An  item  is  a 
variable  of  a  pre-defined  or  programmer-defined  type  having  no 
constituents. 

2.  Table  -  An  aggregate  data  object  consisting  of  a  collection  of 
one  or  more  items,  or  an  array  of  such  collections.  The 
collection  of  items  is  called  an  entry.  An  entire  entry  in  a 
table  is  selected  by  the  use  of  the  table  name,  together  with 
a  sequence  of  indices  ("subscripts")  if  the  table  is  arrayed. 
An  item  within  an  entry  is  selected  by  the  use  of  the  item 
name  and  the  appropriate  number  of  subscripts. 

3*  Block  -  A  group  of  items  and  tables  and  other  blocks  to  which 
is  allocated  a  contiguous  area  of  storage. 

Additionally,  an  item  or  table  may  be  declared  to  be  CONSTANT,  in 
which  case  its  value  cannot  be  changed  during  execution.  A  constant 
item  must  be  given  an  initial  value  by  means  of  an  <ltem-preset>. 
Blocks,  items,  or  tables  (other  than  constants)  can  specify,  by  means  of 
an  <allocatlon-speclf ier> ,  the  allocation  permanence  of  the  storage 
associated  with  their  names.  Non-constant  items  and  tables  can 
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optionally  be  given  initial  values  by  mean8  of  <item-presets>  or 
<table-preseta> . 

The  value  of  an  uninitialized  data  object  is  undefined  until  it 
recelvea  a  value  in  an  executable  statement* 

Declarations  associate  a  <name>  with  a  type*  A  type  determines  the 
set  of  values  that  an  object  can  have  and  the  operations  that  can  be 
performed  on  those  values.  Types  are  grouped  into  related  sets  called 
type  classes.  Examples  of  type  classes  are  signed  Integer,  unsigned 
Integer,  float,  and  bit.  Types  within  a  type  class  are  distinguished  by 
the  values  of  certain  properties  known  as  attributes.  For  example,  S  3 
is  a  particular  type  within  type  class  S  with  a  value  of  3  for  the 
integer  size  attribute.  Rules  concerning  type  matching  are  found  in 
Section  7.0. 


2.1.1  ITEM  DECLARATIONS 


Syntax; 


<ltem-declaratlon> 

•  •  M 

•  • 

ITEM  <item-name> 
[<allocatlon-specifler>] 
<itemrtype-description> 
[<item-preset>]  ; 

(2.1.5) 

(2.1.6) 

<item-name> 

: :» 

<name> 

(8.2.1) 

<item-type-description> 

:  :■ 

<integer-type-description> 

(2. 1.1.1) 

1 

<f looting- type-description> 

(2. 1.1.2) 

1 

<f ixed-type-description> 

(2.1 .1.3) 

1 

<bit-type-description> 

(2. 1.1.4) 

1 

<character-type-description> 

(2. 1.1.5) 

1 

<status-type-description> 

(2. 1.1. 6) 

1 

<pointer-type-description> 

(2. 1.1.7) 

Semantics: 


<Itemr-deelaratlons>  declare  items.  Items  are  used  as  variables  to 
retain  values  in  a  J73  program.  Allocation  for  items  declared  in 
<item-declaratlons>  will  be  such  that  no  items  share  a  word. 
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The  <item-type-description>  establishes  the  type  of  an  item. 

The  <allocation-specifier>  establishes  the  allocation  permanence  of 
Items  which  are  not  enclosed  In  blocks*  This  allocation  permanence  is 
automatic  if  the  declaration  is  in  a  subroutine  and  the 
<allocation-specifier>  la  omitted,  otherwise  it  is  STATIC  (see  Section 
2.1.5).  Items  enclosed  in  blocks  inherit  the  allocation  permanence  of 
the  enclosing  block. 

The  <item-preset>,  if  present,  specifies  an  initial  value  for  the 

item. 

Constraints: 


Only  items  having  STATIC  allocation  (explicitly  or  by  default)  may 
contain  an  <item-preset>. 

Declarations  of  items  that  are  <formal-input-parameters>  or 
<formal-output-parameters>  (see  Section  3.3)  must  not  contain  an 
<allocation-speclfier>  or  <item-preset> . 

An  <i tern-dec la ratlon>  within  a  block  must  not  contain  an 
<allocation-specif ler> . 


2. 1.1.1  INTEGER  TYPE  DESCRIPTIONS 
Syntax: 

<integer-type- 
descrlptlon> 


<integer-i tem- 
descrlptlon> 


<integer-size> 

<integer-type-name> 

Semantics : 

An  <integer-type-description>  is  used  to  specify  a  signed  integer 
type  or  an  unsigned  integer  type.  S  specifies  a  signed  integer  type;  U 
specifies  an  unsigned  integer  type. 


:  <integer-item-description> 

I  <integer-type-name> 

S  {<round-or-truncate>]  (2. 1.1. 2) 

[ <integer-size> ] 

I  U  [<round-or-truncate>]  (2. 1.1. 2) 

[<integer-size>] 

<compile-time-integer-f ormula>  (5.1.1) 

:  <item-type-name>  (2.2) 


i 
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The  <integer-size>  attribute  specifies  the  minimum  number  of  bits 
of  storage  required  to  hold  the  maximum  value  of  the  integer  (excluding 
the  sign,  if  any).  If  <integer-size>  is  omitted,  it  defaults  to 
INTPRECISION.  The  number  of  bits  allocated  for  signed  integers  will  be 
at  least  <integer-size>+l ,  and  for  unsigned  integers  will  be  at  least 
<integer-size> . 

The  value  set  for  a  signed  integer  type  with  size  SS  is  MININT(SS) 
through  MAXINT(SS).  The  value  set  for  an  unsigned  integer  type  with 
size  SS  is  0  through  MAXINT(SS). 

The  <round-or-truncate>  attribute  specifies  truncation  or  rounding 
is  to  occur  when  a  value  is  converted  to  an  integer  type.  If  R  is 
specified,  rounding  will  occur.  If  T  is  specified,  truncation  towards 
minus  infinity  will  occur.  If  Z  is  specified,  truncation  towards  zero 
will  occur.  If  the  attribute  is  omitted,  truncation  in  an 
implementation-dependent  manner  will  occur. 

Constraints : 

The  maximum  value  that  can  be  specified  for  <integer-size>  is 
MAXINTSIZE,  an  implementation  parameter. 

<Integer-size>  must  be  greater  than  zero. 

An  <integer-type-name>  must  be  an  <item-type-name>  declared  in  an 
<item-type-declaration>  that  contains  an  <integer-type-description>  (see 
Section  2.2). 

Notes: 

An  implementation  may  choose  MAXINTSIZE  >  BITSINWORD-l . 

The  <round-or-truncate>  option  has  a  use  only  when  an 
<integer-item-description>  is  used  in  an  <integer-conversion>  (see 
Section  7.0). 

2. 1.1. 2  FLOATING  TYPE  DESCRIPTIONS 


Syntax: 

<floating-type-description>  : :■  <floating-item-description> 

|  <floating-type-name> 

<floating-item-description>  : F  [<round-or-truncate>] 

[<precision>] 
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<round-or-truncate>  ::*  ,  R 

I  ,  T 

I  ,  z 

<precision?  :  :■  <compile-time-integer-formula>( 5.1.1) 

<floating-type-name>  ::■  <item-type-name>  (2.2) 

Semantics : 

A  <floa£ing-type-descrlption>  is  used  to  specify  a  floating  type. 
The  <preclslon>  attribute  specifies  the  minimum  number  of  bits  of 
storage  required  to  hold  the  value  of  the  mantissa.  If  <preclslon>  is 
omitted.  It  defaults  to  FLOATPRECISION,  an  implementation  parameter. 

The  <round-or-truncate>  attribute  is  used  to  specify  whether 
truncation  or  rounding  is  to  occur  when  a  value  of  a  floating  type  with 

a  greater  <preclslon>  is  assigned  to  an  item  of  this  type.  If  R  is 

specified,  rounding  will  occur.  If  T  is  specified,  truncation  towards 
minus  Infinity  will  occur.  If  Z  is  specified,  truncation  towards  zero 
will  occur.  If  the  attribute  is  omitted,  truncation  in  an 
implementation-dependent  manner  will  occur.  Rounding  and  truncation 
take  place  with  respect  to  the  implemented  precision  of  the  floating 
type.  (Note:  IMPLFLOAT?R£CISI0N(PP)  is  an  implementation  parameter 
defining  what  precision  is  provided  when  precision  PP  is  specified.) 

The  value  set  for  a  floating  type  with  <precision>  PP  is 

MINFLOAT(PP)  through  -FLOATUNDERFLOW(PP) ,  0,  and  FLOATUNDERFLOW(PP) 

through  MAXFLOAT(PP). 

Constraints: 

The  maximum  value  that  can  be  specified  for  <precislon>  is 

MAXFLOATP RECI S ION ,  an  Implementation  parameter. 

<?recision>  must  be  greater  than  zero. 

A  <floating-type-name>  must  be  an  <item-type-name>  declared  in  an 
<item-type-declaration>  that  contains  a  <floating-type-description>  (see 
Section  2.2). 

Note: 

Since  a  <floating-type-descrlption>  specifies  only  the  minimum 
precision  required,  an  Implementation  is  free  to  support  only  one  or  two 
levels  of  implemented  precision.  Which  implemented  precision  level 
represents  a  floating  type  depends  on  the  value  of  the  specified 
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precision.  The  implemented  precision  must  never  be  less  then  the 
specified  precision.  Since  sn  implementation  may  provide  more  than  the 
specified  precision,  it  is  consistent  to  round  or  truncate  a  represented 
value  only  if  converting  from  a  longer  to  a  shorter  implemented 
precision. 


2. 1.1. 3  FIXED  TYPE  DESCRIPTIONS 
Syntax; 

<f ixed-type-description> 


<f ixed-i t em-de scrip t i on> 


<scale-speclfler> 

<fraction-specifier> 

<f ixed-type-name> 

Semantics: 

A  <fixed-type-description>  is  used  to  specify  a  fixed  point  numeric 
type.  If  SS  is  the  value  of  the  <scale-specifier>  and  FF  is  the  value 
of  the  <f raction-specifier> ,  then  SS+FF  is  the  minimum  number  of  bits  in 
the  representation,  excluding  the  sign  bit.  When  SS  and  FF  are  both 
positive,  SS  specifies  the  number  of  bits  to  the  left  of  the  binary 
point  (excluding  the  sign  bit)  and  FF  the  minimum  number  of  bits  to  the 
right  (see  Note  below).  When  SS  is  negative,  the  binary  point  is 
assumed  to  be  ABS(SS)  bits  to  the  left  of  the  first  (non-sign)  bit  of 
the  representation.  Similarly,  when  FF  is  negative,  the  least 
significant  bit  of  the  representation  is  no  more  than  ABS(FF)  bits  to 
the  left  of  the  binary  point. 

The  (nominal)  precision  of  a  fixed  point  type  is  the  sum  of  its 
scale  and  fraction  specifier.  The  Implemented  precision  may  be  greater 
than  the  nominal  bits  required.  If  <fraction-specif ier>  is  omitted,  the 
fixed  point  type  has  a  default  precision  given  by  FIXEDPRECISION,  an 
implementation  parameter,  and  the  implied  value  of  the  omitted 
<fraction-specif ier>  is  FIXEDPRECIS10N-SS,  where  SS  is  the  <scale- 
speclfler>. 

If  FF  is  a  fixed  point  item  declared  with  a  default 

<f raction-speclf ier> ,  then  FIXEDPRECISION  -  BITSIZE(REP(FF))-1 . 


:*  <f ixed-i t em-de script ion> 

J  <f ixed-type-name> 

;«  A  [<round-or-truncate>] 
<scale-specif ier> 

[,  <fraction-specifier>J 


(2. 1.1.2) 


<compile-time-integer-f ormulaX  5.1.1) 
<compile-time-integer-formula>(5.1 .1) 
<itemrtype-name>  (2.2) 
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The  <round-or-truncate>  attribute  specifies  truncation  or  rounding 
is  to  occur  when  a  value  is  converted  to  a  fixed  point  type.  If  R  is 
specified,  rounding  will  occur.  If  T  is  specified,  truncation  towards 
minus  infinity  will  occur.  If  Z  is  specified,  truncation  towards  zero 
will  occur.  If  the  attribute  is  omitted,  truncation  in  an 
implementation-dependent  manner  will  occur.  Rounding  and  truncation 
take  place  with  respect  to  the  Implemented  precision  of  the  fixed  type 
(see  Note  below). 

The  value  set  of  a  fixed  point  type  with  scale  SS  and  fraction  FP 
is  MINFIXED(SS.FF)  through  MAXFIXED(SS.FF) . 

Constraints; 

The  sum  of  the  scale  and  fraction  specifiers  (l.e.,  the  nominal 
precision)  must  be  greater  than  zero  and  must  not  exceed 
MAXFIXEDPRECISION,  an  implementation  parameter. 

The  value  of  <scale-specif ier>  must  lie  in  the  range  -127  through 

+127. 

A  <f ixed-type-name>  must  be  an  <item-type-name>  declared  in  an 
<item-type-declaration>  that  contains  a  <fixed-type-descrlption>  (see 
Section  2.2). 

Notes : 


The  set  of  exactly  representable  fixed  point  values  is  determined 
by  a  fixed  type's  scale  and  fraction  specifiers.  A  <fraction- 
specifler>  value,  FF,  means  fixed  point  values  must  be  represented  with 
a  precision  greater  than  or  equal  to  2**(-FF).  A  <scale-specif ier> 
value,  SS,  means  the  maximum  representable  value  is  at  least  2**SS  - 
2**(-FF)  and  less  than  2**SS. 

An  implementation  is  permitted  to  support  more  than  one  level  of 
implemented  precision  for  fixed  point  types.  For  computational 
purposes,  values  will  be  represented  using  the  smallest  implemented 
precision  level  (e.g.,  one  word  or  two  words)  consistent  with  the 
value's  nominal  precision.  For  storage  purposes  in  packed  tables,  a 
fixed  point  value  need  occupy  no  more  than  the  number  of  bits  specified 
by  the  nominal  precision  plus  one  bit  for  the  sign. 

IMPLFIXEDPR£CISION(SS,FF)  is  an  implementation  parameter  defining 
what  precision  is  provided  for  an  unpacked  fixed  point  item  when  nominal 
precision  SS+FF  is  specified.  In  addition,  the  implemented  precision  of 
a  packed  item  (i.e.,  an  item  in  a  specified  table,  packed  ordinary 
table,  or  a  tight  table)  as  well  as  an  unpacked  item  is  given  by 
BITSIZE(REP(FI) )-l ,  where  FI  is  the  fixed  point  item. 
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Th«  implemented  precision  of  e  fixed  item  is  the  number  of  bits 
(excluding  sign  bit)  used  to  store  the  item.  Assignments  to  such  items 
round  or  truncate  with  respect  to  this  precision,  which  is  never  less 
than  the  specified  precision.  Rounding  or  truncation  can  change  a  fixed 
point  value  only  if  the  implemented  precision  is  shortened. 

It  should  be  noted  that  specifying  R,  T,  or  Z  in  an  item 
declaration  only  affecta  the  conversion  of  literal  values  (see  Section 
8.3.1)  and  assignments  of  fixed  point  values  when  the  stored 
representation  of  the  value  is  shorter  than  the  representation  used  for 
computations . 


2.1 .1.4  BIT  TYPE  DESCRIPTIONS 


Syntax; 


<bit-type-deacription> 

<bi t-i tem-descrip  t ion> 
<bit-size> 

<bi C-eype-name> 


:  :■  <bit-item-description> 

I  <b  i  t- ty pe-name> 

B  [<bit-size>] 

<compile-time-integer-formula>  (5.1.1) 
<item-type-name>  (2.2) 


Semantics: 

A  <bit-type-description>  is  used  to  specify  a  bit  string  type.  The 
<bit-size>  attribute  specifies  the  number  of  bits  in  the  string.  If 
<bit-size>  is  omitted  it  defaults  to  1 . 


Constraints: 

The  maximum  value  that  can  be  specified  for  <bit-size>  is  MAXBITS, 
an  Implementation  parameter.  The  minimum  value  that  can  be  specified 
for  <bit-size>  is  one. 

A  <bit-type-name>  must  be  an  <item-type-name>  declared  in  an 
<itemr'type-declaration>  that  contains  a  <bit-type-description>  (see 
Section  2.2). 
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2 . 1 . 1 .5  CHARACTER  TYPE  DESCRIPTIONS 


Syntax; 

<character-type-description>  ::» 

I 

<character-item-description>  ::■ 
<character-size> 

<character-type-name>  : :• 

Semantics: 


<character-ltem-descrlption> 

<character-type-name> 

C  [<character-size>] 
<compile-time-integer-fommla>(5.1 .1) 
<item-type-name>  (2.2) 


A  <character-type-description>  Is  used  to  specify  a  fixed-length 
character  string  type.  The  <character-size>  attribute  specifies  the 
number  of  characters  in  the  string.  If  <character-size>  is  omitted  it 
defaults  to  1. 

Constraints: 


The  maximum  value  chat  can  be  specified  for  <character-size>  is 
MAXBYTES ,  an  implementation  parameter.  The  minimum  value  that  can  be 
specified  for  <character-size>  is  one. 

A  <character-type-name>  must  be  an  <item-type-name>  declared  in  an 
<item-type-declaration>  that  contains  a  <character-type-description> 
(see  Section  2.2). 


2. 1.1. 6  STATUS  TYPE  DESCRIPTIONS 


Syntax: 

<status-type-description> 

<status-item-description> 

<status-list> 


■  <status-item-description> 
|  <status-type-name> 

■  STATUS  [<status-size>] 

(  <status-list>  ) 

■  <default-sublist> 

|  [<default-sublist>  , ] 
<specif ied-sublisc> , . . . 
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<default-sublist> 

:  :• 

<status-constant> , . . . 

<speclfied-subllst> 

•  •  ® 

<status-list-index> 
<status-constant> , . . . 

<statu8-list-lndex> 

*  *  S 

<compile-time-integer-fonnula>  (5.1.1) 

<statu8-constant> 

•  •  M 

•  • 

V  (  <status>  ) 

<status> 

:  :■ 

<name> 

(8.2.1) 

1 

<letter> 

(8.1) 

1 

<reserved-word> 

(8.2.2) 

<s  t a  tus- type-name> 

»  •  a 
•  • 

<i tem-type-name> 

(2.2) 

<status-size> 

•  •  M 

•  • 

<compile-time-integer-formula> 

(5.1.1) 

Semantics: 

A  <status-type-description>  is  used  to  specify  a  status  type.  The 
<scatus-list>  is  used  to  define  the  value  set  of  the  type,  which 

consists  of  a  set  of  named  <status-constants>.  These  named 
<scatus-constants>  are  considered  to  be  the  logical  values  of  the  status 
type.  Associated  with  each  logical  value  is  a  representational  value, 
i.e.,  how  the  value  is  actually  represented  internally.  If  the 
<status-list>  contains  only  a  <default-sublist> ,  the  status  type  is  said 
to  have  a  default  representation.  The  <status-constants>  in  the 
<de fault- sublist>  will  be  assigned  representational  values  0  through  N-l 
(where  N  is  the  number  of  <status-constants>  in  the  sublist)  in  the 
order  in  which  they  are  specified  in  the  list.  The  <status-constants> 
in  each  <specified-sublist>  will  be  assigned  representational  values 
<status-list-index>  through  <status-list-index>  +  N-i  (where  N  is  the 
number  of  <status-constants>  in  the  sublist)  in  the  order  in  which  they 
are  specified. 

For  a  given  <status-llst> ,  the  value  of  any  <status-constant>  is 
considered  to  be  greater  than  the  value  of  another  <status-constant> 
having  a  lower  representational  value. 

<Status-size>  specifies  the  minimum  number  of  bits  to  be  allocated 
to  hold  the  status  value  (excluding  the  sign  bit,  if  any).  If  it  is 
omitted,  it  defaults  to  the  minimum  needed  for  the  representation  as  an 
Integer  value.  If  the  representation  of  the  lowest-valued 
<status~constant>  in  the  list  is  less  than  zero,  signed  integer 
representation  will  be  used;  otherwise,  unsigned  integer  representation 
will  be  used. 


MIL-STD-1589B  (USAF) 
06  June  1980 


Constraints: 

The  <status-constants>  oust  be  unique  within  the  <status-liat>. 

The  <status-list-indlces>  within  a  <status-llst>  must  be  specified 
such  that  all  the  <status-constants>  in  the  <status-list>  receive  unique 
representational  values. 

The  value  specified  in  <status-size>  must  be  greater  than  or  equal 
to  the  minimum  needed  for  the  representation  of  the  status  values  and 
less  than  or  equal  to  MAXINTSIZE. 

The  representation  of  a  status  value  cannot  be  less  than  MININT 
( BITSINWORD— 1 )  and  it  cannot  exceed  MAXINT( BITSINWORD- 1 ) . 

A  <status-type-name>  must  be  an  <item-type-name>  declared  in  an 
<item-type-deelaration>  that  contains  a  <status-type-description>  (see 
Section  2.2). 

Note: 


The  use  of  a  <name>  in  a  <status>  does  not  constitute  a  declaration 
of  the  <name>  or  a  reference  to  a  declared  <name>-  having  the  same 
spelling.  Within  a  given  scope,  a  <status>  <name>  and  a  declared  <name> 
can  have  the  same  spelling  and  no  conflict  will  result. 


2. 1.1. 7  POINTER  TYPE  DESCRIPTIONS 
Syntax: 


<pointer-type-description> 

: :■  <pointer-item-description> 

|  <pointer-type-name> 

<pointer-item-description> 

P  [<type-name>] 

<pointer-type-name> 

: :»  <item-type-name> 

(2.2) 

<type-name> 

: <item-type-name> 

(2.2) 

I  <table-type-name> 

(2.2) 

|  <block-type-name> 

(2.2) 

Semantics: 

A  <pointer-type-description>  is  used  to  specify  a  pointer  type.  If 
the  <pointer-item-description>  contains  a  <type-name>,  then  the  pointer 


MIL-STD-1589B  (USAF) 
06  June  1980 


being  specified  is  a  typed  pointer.  If  the  <type-name>  is  omitted,  then 
the  pointer  is  an  untyped  pointer. 

A  typed  pointer  contains  the  address  of  a  data  object  of  the  type 
specified  by  the  <type-name>.  The  object  being  pointed  to  may  be 
obtained  by  dereferencing  the  pointer  (see  Section  6.1). 

An  untyped  pointer  contains  the  address  of  a  data  object  of  any 
type.  However,  such  a  pointer  must  be  converted  to  a  typed  pointer  (see 
Section  7.0)  before  it  may  be  dereferenced  or  assigned  to  a  typed 
pointer. 

Constraint: 


A  <polnter-type-name>  must  be  an  <item-type-name>  declared  in  an 
<item-type-declaration>  that  contains  a  <pointer-type-descrlption>  (see 
Section  2.2). 


2.1.2  TABLE  DECLARATIONS 
Syntax: 


<table-declaration>  :  :«•  TABLE  <table-name> 


[<allocation-specifier>] 

[ <dimenBlon-ll3t> ] 
table-description> 

(2.1.5) 
(2. 1.2.1) 

<table-description> 

: [<structure-specifier>] 
<entry'-specifier> 

(2. 1.2.2) 

|  <table-type-name> 
[<table-preset>]  ; 

(2.2) 

(2.1.6) 

<entry-specifier> 

::«•  <ordinary-entry-specifier> 

(2. 1.2.3) 

|  <specified-entry-specifier> 

e 

CM 

e 

^-1 

e 

CM 

N-/ 

<table-name> 

: :»  <name> 

(8.2.1) 

Semantics : 

<Table-declarations>  declare  named  aggregate  data  objects.  The 
presence  of  a  <dimens ion-1 ist>  indicates  that  the  table  is  an  arrayed 
collection  of  entries.  The  <dimension-list>  specifies  the  range  of 
Indices  of  the  array. 

The  <allocation-speclfier>  establishes  the  allocation  permanence  of 
tables  which  are  not  enclosed  in  blocks.  This  allocation  permanence  is 
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automatic  if  the  declaration  is  In  a  subroutine  and  the 
<allocatlon-speclfler>  is  omitted,  otherwise  it  is  STATIC  (see  Section 
2.1.3)*  Tables  enclosed  in  blocks  inherit  the  allocation  permanence  of 
the  enclosing  block. 

The  <table-descrlption>  describes  the  contents  of  the  table  either 
with  a  <table-cype-name>  (see  Section  2.2)  or  with  an  <entry-specif ier>. 
Two  or  more  tables  may  be  declared  in  the  same  scope  using  the  same 
< table- t ype-name> ,  and  no  name  conflicts  of  the  contained  items  will 
result,  provided  the  <table-names>  are  different.  Items  in  tables 
declared  with  a  < table- type-name>  can  only  be  accessed  using  pointers  to 
the  tables  (see  Section  6.1). 

A  table  may  either  be  an  ordinary  table,  in  which  only  the  logical 
structure  is  described  (see  Section  2. 1.2. 3)  or  a  specified  table,  in 
which  the  detailed  physical  layout  of  the  table  is  described  (see 
Section  2. 1.2.4). 

A  <structure-specifier>  is  used  to  specify  the  representation  of 
entries  in  a  dimensioned  table  (see  Section  2.1 .2.2). 

The  <table-preset> ,  if  present,  specifies  Initial  values  for  the 
table  components.  For  < table-descrip tlons>  containing  an  <entry- 
specifier>  rather  than  a  <table-type-name>,  the  <table-preset>  is  part 
of  the  <entry-speclfier>  (see  Section  2. 1.2. 3  and  2. 1.2 .4). 

Constraints: 

Only  tables  having  STATIC  allocation  (explicitly  or  by  default)  may 
contain  a  <table-preset>. 

Tables  that  are  <f ormal-input-parameters>  or  <formal-output- 
parameters>  (see  Section  3.3)  must  not  contain  an  <allocatlon-specifier> 
or  <table-preset>. 

A  <table-dedaration>  within  a  block  must  not  contain  an 
<allocatlon-specif ier> . 

A  dimensioned  <table-declaratlon>  must  not  contain  a  <table-type- 
name>  whose  declaration  also  contains  a  <dimension-list>. 

A  <structure-specif ier>  in  an  undimensioned  cable  is  prohibited. 


2. 1.2.1  TABLE  DIMENSION  LISTS 
Syntax: 
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<dlaens lon-li • t> 
<dlmenelon> 


<lower-bound-option> 

<lower-bound> 

<upper-bound> 

Semantics: 


(  <dlmenslon>, ...  ) 

: (<lower-bound-option>] 

<upper-bound> 

I  * 

: :»  <lower-bound>  : 

<compile-time-integer-formula>  (5.1.1) 
I  <compile-time-status-formula>  (5.4) 

<coopile-time-integer-formula>  (5.1.1) 
I  <compile-time-status-formula>  (5.4) 


A  <dimension-list>  specifies  that  a  table  Is  an  array.  Each 
<dlaenslon>  specifies  the  range  of  values  for  that  dimension.  If  the 
<lower-bound>  is  omitted,  it  defaults  to  zero  if  the  <upper-bound>  is  an 
integer;  if  the  <upper-bound>  is  a  status  value,  it  defaults  to  the 
first  <status-constant>  in  the  status  type  of  the  <upper-bound> . 

A  <dlmension>  of  *  that  appears  with  a  formal  parameter  means  the 
bounds  will  be  determined  from  the  actual  parameter  on  each  invocation. 
(Note  that  in  accordance  with  Sections  6.3.9  and  6.1,  bounds  of  * 
dimensions  range  from  0  to  NN-l ,  where  NN  is  the  number  of  elements  in 
the  corresponding  dimension  of  the  actual  parameter,  regardless  of  what 
the  lower  and  upper  bounds  vslues  are  for  the  actual  parameter  or 
whether  the  bound  has  an  integer  or  status  type.) 

Constraints: 

Only  status  types  with  default  representations  may  be  used  in 
<dimensions> . 

The  <lower-bound>  must  be  less  than  or  equal  to  the  <upper-bound> . 

The  <lower-bound>  and  <upper-bound>  must  both  be  status  formulas 
of  the  same  type  or  both  be  integer  formulas. 

The  maximum  number  of  <dlmensions>  is  seven. 

A  <dimension>  of  *  may  be  used  only  with  a  table  formal  parameter. 

If  any  <dimension>  of  a  table  formal  parameter  Is  specified  as  *, 
they  all  must  be  specified  as  *. 
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The  number  of  words  occupied  by  a  table  must  not  exceed 
MAXTABLESIZE. 


2. 1.2. 2  TABLE  STRUCTURE 
Syntax: 

<s true ture-s pecif ier> 


<bi ts-per-ent ry> 

Semantics : 

Dimensioned  tables  can  have  a  parallel  or  serial  structure.  In 
addition,  a  serial  table  may  be  tightly  structured.  The 
<strueture-speclfier>  specifies  the  cable  structure. 

A  <strueture-specifier>  PARALLEL  indicates  parallel  structure.  For 
cables  with  parallel  structure,  the  first  word  (word  0)  of  each  entry  is 
allocated  consecutively,  then  word  one,  etc.  An  omitted 
<structurer*specifier>  or  one  with  T  indicates  serial  structure.  For 
tables  with  a  serial  structure,  all  words  of  the  first  entry  are 
allocated  consecutively,  Chen  all  words  of  the  next  entry,  etc.  Entries 
in  both  parallel  and  serial  tables  are  arranged  such  that  the  rightmost 
indices  vary  fastest,  from  the  lower  bound  to  the  upper  bound. 

A  <structure-specif ier>  of  T  indicates  tight  structure  (in  addition 
to  serial  structure).  Tight  structure  defines  the  allocation  of  storage 
between  entries  in  a  dimensioned  (ordinary  or  specified)  table,  whereas 
packing  (see  Section  2. 1.2. 3)  defines  the  allocation  of  storage  within 
an  entry  of  an  ordinary  table.  Tight  structure  indicates  that  multiple 
entries  of  a  dimensioned  table  are  to  be  stored  within  a  single  word 
such  that  no  entry  crosses  a  word  boundary.  <Bits-per-entry>  specifies 
Che  number  of  bits  each  entry  is  to  occupy.  If  it  is  omitted,  it  will 
default  to  the  minimum  number  of  bits  needed  to  store  the  entry. 

Entries  in  tightly-structured  Cables  are  right-justified  in  the 
bits  allotted. 

Entries  in  tables  without  a  <structure-specif ier>  of  T  shall  not 
share  a  word. 

Constraints: 


: :-  PARALLEL 

|  T  [<bits-per-entry>] 

<compile-time-integer-f ormula>  (5.1.1) 


<Bits-per-entry>  must  be  equal  to  or  greater  than  Che  minimum 
number  of  bits  needed  to  store  the  entry. 
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The  explicit  or  default  value  of  <bits-per-entry>  must  be  less  than 
or  equal  to  BITSINWORD. 

Items  In  a  parallel  table  must  not  cross  word  boundaries. 

A  parallel  table  must  contain  a  <dimena ion-1 ist>. 


2. 1.2. 3  ORDINARY  TABLE  ENTRIES 
Syntax; 

<ordinary-entry- 


specifier> 

:  :*  [ <packing-specif ier>  ] 

<item-type-description> 
[<table-preset>]  ; 

(2.1.1) 

(2.1.6) 

|  [<packlng-specifler>] 
[<table-preset>]  ; 
<ordinary-table-body> 

(2.1.6) 

<packing-specifier> 

N 

I  M 


» 

1  o 

<ordinary-table-body> 

; <ordinary-table-item-declaration> 

I  BEGIN 

<ordinary-table-option8> . . . 

END 

<ordinary-table-ite»- 

declaratlon> 

ITEM  <table-item~name> 
<item-cype-description> 
t  <packing-specif ler> ] 
[<table-presec>]  ; 

(2.1.1) 

(2.1.6) 

<table-item-name> 

: :■  <name> 

(8.2.1) 

<ordlnary-table-options> 

: <ordinary-table-item-declaration> 

|  <directive> 

(9.0) 

|  <null-declaration> 

(2.7) 
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An  <ordinary-entry-specif ier>  is  used  to  specify  the  contents  of  an 
entry  of  an  ordinary  table. 

No  allocation  order  Is  implied  by  the  order  of  items  in  the 
<ordinary-table-optlons>  unless  the  <ordinary-table-options>  contains  an 
<order-directive>.  If  an  <order-directive>  is  not  in  effect, 
<ordinary-table-options>  will  be  reordered,  if  necessary,  to  reduce  the 
storage  occupied  by  an  entry,  consistent  with  the  <packing-specif ier> . 
Tables  having  the  same  type  will  have  the  same  representation. 


The  <packing-specifler>  specifies  the  density  with  which  items  are 
allocated  within  an  entry.  The  following  three  degrees  of  packing  can 
be  specified: 

1.  N  Indicates  that  the  items  are  not  packed.  No  items  share  a 
word . 

2.  M  indicates  a  density  of  packing  that  can  be  between  N  and  D. 

The  exact  meaning  is  implementation-dependent,  and  is 

specified  to  be  an  effective  compromise  between  space  usage 
and  accessing  ease. 

3.  D  indicates  dense  packing.  Items  are  allocated  adjacent  bits 
in  a  word  with  the  following  exceptions: 

a.  Non-character  items  one  word  or  longer  start  on  a 
word  boundary.  Shorter  non-character  items  do  not 
cross  word  boundaries. 

b.  Each  byte  of  a  character  item  which  crosses  a  word 
boundary  must  be  allocated  on  a  byte  boundary.  An 
implementation  may  (but  need  not)  allocate  the  bytes 
of  other  character  items  on  byte  boundaries. 

A  <packing-specif ier>  preceding  an  <ordinary-table-body>  in  an 
<ordinaryentry-specifier>  applies  to  all  items  in  the  <ordinary- 
table-body>  that  do  not  themselves  include  a  <packing-specif ier>  in 
their  declaration. 

Default  packing  for  a  tightly-structured  table  (see  Section 
2. 1.2. 2)  is  D;  for  all  other  tables,  it  is  N. 

The  value  of  unallocated  bits  in  an  <ordinary-entry-specifier>  is 
implementation-dependent. 

The  <table-preset>,  if  present,  specifies  initial  values  for  the 
table  entries. 
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Constraints: 

Only  tables  having  STATIC  allocation  (implicitly  or  explicitly)  may 
contain  a  <table-preset>. 

Declaration  of  table  <formal-input-parameters>  or 

<formal-output-parameters>  (see  Section  3.3)  must  not  contain 
<table-presets>. 

If  a  <table-preset>  precedes  the  <ordinary-table-body>,  none  of  the 
<ordinary-table-item-dedarationa>  in  the  <ordinary-table-body>  can 
contain  a  <table-preset> . 

An  <ordinary-entry-specifier>  used  in  a  <table-type-declaration> 
(see  Section  2.2)  must  not  contain  a  <table-preset>. 

An  <ordinary-table-options>  must  contain  at  least  one  <ordinary- 
table-item-declaration> . 

A  <packing-specif ier>  of  N  is  permitted  in  1  tightly-structured 
table  only  if  the  table  entry  contains  only  one  item. 

The  number  of  words  allocated  for  a  table  entry  must  not  exceed 
MAXBITS/BITSINWORD . 


2. 1.2 .4  SPECIFIED  TABLE  ENTRIES 


Syntax: 

<specified-entry- 

specifier> 


<words-per-entry> 


<entry-size> 


:  :■  <words-per-entry> 

<specif ied-i tem-description> 
[<table-preset>]  ;  (2.1.6) 

|  <words-per-entry> 

[<table-preset> J  ;  (2.1.6) 

<  s  pecif led- table-body> 

W  [ <entry-size> ] 

I  V 

::■  <compile-time-integer-formula>  (5.1.1) 


<specif ied-i tem- 
descriptlon> 


<iteo-type-description>  POS 
(  <location-specifier>  ) 


(2.1.1) 
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<location-speclf ier> 

•  •  M 

•  • 

<starting-bit>  , 

<starting-word> 

<starting-bit> 

•  •  M 

•  • 

1 

<compile-time-integer-formula> 

* 

(5.1.1) 

<starting-word> 

1 

*  *  H 

•  • 

<compile-time-integer-formula> 

(5.1.1) 

<specified-table-body> 

•  *  SB 

•  • 

<specif ied-table-item-declaration> 

1 

BEGIN 

<specif ied-table-options> ... 

END 

<specified-table-item- 

declaratlon> 

ITEM  <table-item-name> 

<specif ied-item-description> 
[<table-preset>]  ; 

(2. 1.2.3) 

(2.1.6) 

<specified-table> 

optlons> 

<specified-table-item-declaration> 

1 

<directive> 

(9.0) 

1 

<null-declaration> 

(2.7) 

Semantics : 


A  <speclf led-entry-specif ler>  is  used  to  specify  the  contents  of  an 
entry  of  a  specified  table. 

<Words-per-entry>  specifies  the  size  of  (i.e,  number  of  words  in) 
each  entry  in  the  table.  <Words-per-entry>  containing  a  W  indicates  a 
fixed-length-entry  specified  table  whereas  V  indicates  a 
variable-length-entry  specified  table.  In  a  fixed-length-entry 
specified  table,  <entry-size>  (if  present)  specifies  the  number  of  words 
allocated  to  each  entry  In  the  table.  In  a  tightly-structured  table  (in 
which  <entry-size>  must  be  omitted),  the  size  of  the  entry  is  determined 
from  the  <structure-specif ier>.  In  a  variable-length-entry  specified 
table,  each  entry  is  allocated  one  word. 

The  <location-specif ier>  specifies  the  physical  location  of  the 
item  from  the  start  of  the  entry.  <Starting-word>  Indicates  at  which 
word  of  the  entry,  starting  from  zero,  the  item  is  to  start,  and 
<starting-bit>  indicates  at  which  bit  in  the  word,  starting  from  zero  at 
the  leftmost  part  of  the  word,  the  item  is  to  start.  In  the  case  of 
entries  in  tightly  structured  tables,  <starting-bit>  is  considered  to  be 
relative  to  the  start  of  the  entry.  A  <starting-bit>  of  *  indicates 
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chat  che  lcea  should  occupy  che  same  amount  of  storage  and  be  aligned  in 
the  same  way  it  would  if  it  were  allocated  outside  a  table,  in  order  to 
ensure  efficient  access  to  the  item.  These  rules  apply  to  both 
fixed-length-entry  and  to  variable-length-entry  specified  tables. 
Consequently,  in  a  varlable-lengch-entry  table,  reference  to  an  item 
with  subscript  NN  will  reference  that  item  relative  to  the  start  of  the 
NNth  entry,  where  each  entry  is  considered  to  be  one  word  long  (l.e.,  a 
subscript  of  NN  does  not  refer  to  the  NNth  logical  entry  in  that  table). 
It  is  entirely  up  to  the  programmer  to  keep  track  of  the  actual  length 
of  logical  entries  in  such  tables. 

The  <table-preset>,  if  present,  specifies  initial  values  for  the 
cable  entries. 

The  value  of  unallocated  bits  in  a  <speclfled-table-entry>  is 
implementation-dependent . 

Constraints: 

<Entry-size>  must  be  omitted  on  tightly-structured  tables  and  must 
be  present  otherwise. 

<Entry-size>  must  be  greater  than  zero  and  less  than  or  equal  to 
MAXBITS/BITSINWORD  . 

<Starting-word>  must  be  non-negative.  For  items  in  tables  with 
entry  sizes  specified  by  <entry-size> ,  <starting-word>  plus  number  of 
words  occupied  by  the  item  must  not  exceed  <entry-size>.  For  tightly 
structured  cables  <starting-word>  must  be  zero. 

<Startlng-bit>  must  be  non-negative  and  must  not  cause  item 
position  to  violate  other  positioning  constraints.  For  non-tightly 
structured  tables  it  must  also  be  less  than  BITSINWORD.  For  tightly 
structured  tables  <starting-bit>  plus  number  of  bits  occupied  by  che 
item  must  not  exceed  <bits-per-entry>. 

Only  Cables  having  STATIC  allocation  (implicitly  or  explicitly)  may 
contain  a  <table-preset>. 

Tables  that  are  <formal-input-parameters>  or 

<formal-output-parameters>  (see  Section  3.3)  must  not  contain  a 
<table-preset> . 

If  a  <cable-preset>  precedes  the  <speclfled-table-body>,  none  of 
the  <specified-table-item-declarationa>  in  the  <speclfled-table-body> 
can  contain  a  <table-preset>.  If  any  part  of  an  item  in  a 
<specified-table-body>  overlaps  any  part  of  another  Item  in  the  table 
body,  only  one  of  the  items  can  be  preset. 
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A  <speclf ied-entry-specif ler>  used  In  a  <table-type-declaratlon> 
(see  Section  2.2)  must  not  contain  a  <table-preset>. 

A  <speclf led-table-optlons>  must  contain  at  leaat  one  <specified- 
table-ltem-declaratlon>. 

Non-character  Items  whose  size  is  one  word  or  less  cannot  cross  a 
word  boundary.  Character  Items,  regardless  of  length,  may  start  on  any 
byte  boundary,  l.e.,  any  value  of  the  machine  parameter  BYTEPOS.  Any 
<starting-bit>  value  Is  permitted  for  character  items  that  do  not  cross 
word  boundaries. 

An  Implementation  may  restrict  legal  <startlng-blt>  values  for 
pointer  items  that  are  Initialized. 

Variable-length-entry  specified  tables  must  contain  a 
<speclf led— table-body),  and  they  cannot  contain  <table-presets>  or 
<s  tructure-specif lers> . 


2.1.3  CONSTANT  DECLARATIONS 
Syntax: 

<constant-declaratlon>  : :»  CONSTANT  ITEM 

<constant-item-name> 

<item-type-description>  (2.1.1) 

<item-preset>  ;  (2.1.6) 

|  CONSTANT  TABLE 

<constant-table-name> 

[<dlmension-list>]  (2. 1.2.1) 

<table-description>  (2.1.2) 

<constant-item-name>  : <name>  (8.2.1) 

<constant-table-name>  : <name>  (8.2.1) 

Semantics: 


A  <constant-declaration>  creates  an  item  or  table  whose  value  must 
be  set  by  means  of  an  <item-preset>  or  <table-preset>  and  whose  value 
cannot  be  changed  during  execution  of  a  program.  The  value  of  a 
constant  item  whose  type  class  is  not  pointer  can  be  used  in  a 
<compile-time-f ormula>  (see  Section  5.0).  The  value  of  a  constant  table 
or  an  item  within  a  constant  table  may  not  be  used  in  a 
<compile-time-f ormula> . 
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Physical  storage  will  be  allocated  for  all  <constant-declaratlons> 
that  are  In  <block-declaratlons>. 

The  allocation  permanence  of  all  allocated  <constant-declaratlons> 
Is  considered  to  be  STATIC,  even  If  the  4eclarations  appear  In  a 
<subroutlne-def inltlon> . 

2.1.4  BLOCK  DECLARATIONS 
Syntax; 

<block-declaratlon>  : :■  BLOCK  <block-naoe> 

[<allocation-specifier>]  ;  (2.1.5) 


<block-body-part> 

I  BLOCK  <block-name> 

[<allocation-speclfier>]  (2.1.5) 

<block-type-name>  (2.2) 

[<block-preset>]  ;  (2.1.6) 

<block-name>  <name>  (8.2.1) 

<block-body-part>  :  <null-dedaration>  (2.7) 

•  |  <data-declaration>  (2.1) 

I  BEGIN 

<block-body-options> . . . 

END  (9.0) 

<block-body-optlons>  : <data-declaratlon>  (2.1) 

|  <overlay-declaration>  (2.6) 

|  <directive>  (9.0) 

I  <null-declaratlon>  (2.7) 

Semantics : 


A  <block-declaratlon>  declares  a  group  of  Items,  cables,  and  other 
blocks  that  are  to  be  allocated  In  a  contiguous  area  of  storage.  No 
allocation  order  Is  implied  by  the  order  of  the  declarations  within  a 
block  unless  the  <block-body-options>  contains  an  <order-directive>.  If 
an  <order-directlve>  is  not  in  effect,  <block-body-options>  will  be 
reordered,  if  necessary,  to  improve  accessibility. 


34 


MIL-STD-1589B  (USAF) 
06  June  1980 


The  <allocatlon-specif ier>  establishes  the  allocation  peraanence  of 
blocks  which  are  not  enclosed  in  blocks.  This  allocation  peraanence  is 
automatic  if  the  declaration  is  in  a  subroutine  and  the 
<allocation-specifier>  is  omitted,  otherwise  it  is  STATIC  (see  Section 
2.1.S).  Blocks  enclosed  in  blocks  inherit  the  allocation  permanence  of 
the  enclosing  block. 

The  <block-declaration>  describes  the  contents  of  tho  block  either 
with  a  <block-type-name>  (see  Section  2.2)  or  with  a  <block-body-part> . 
The  <block-body-part>  contains  explicit  declarations  of  all'  the 
components  of  the  block. 

The  <block-preset>,  if  present,  specifies  initial  values  for  the 
block  components.  For  <block-declarations>  containing  a  <block-body— 
part>  rather  than  a  <block-type-name> ,  Initial  values  may  be  specified 
with  <block-presets>,  <table-presets>  and  <item-presets>  on  the 
components  themselves. 

Constraints : 

Only  blocks  having  STATIC  allocation  (explicitly  or  by  default)  may 
contain  a  <block-preset>  or  a  <data-declaration>  containing  an  <item- 
preset>,  <table-preset>  or  <block-preset>. 

If  a  <constant-declaration>  is  in  a  block,  the  block  must  have 
STATIC  allocation  (explicitly  or  by  default). 

<Data-declarations>  within  a  block  must  not  contain  an  Allocation- 
specifier^ 

Blocks  that  are  <formal-lnput-parameters>  or  <foraal-output- 
parameters>  (see  Section  3.3)  must  not  contain  an  Allocation- 
specifier^  a  <block-preset>  or  a  <data-declaration>  with  an 
<item-preset>,  <table-preset> ,  or  <block-preset> . 

Components  of  blocks  declared  with  a  <block-type-name>  may  be 
accessed  only  by  using  pointers  to  Che  blocks. 


2.1.5  ALLOCATION  OF  DATA  OBJECTS 
Syntax: 

Allocatlon-specifler>  STATIC 

Semantics: 

Allocation  of  storage  for  a  data  object  can  be  STATIC  or  automatic. 
STATIC  allocation  means  that  the  data  object  is  to  exist  throughout  the 
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entire  execution  of  the  program.  Automatic  allocation  ia  applicable 
only  to  data  declared  within  subroutines  and  means  that  the  data  object 
need  only  exist  while  the  subroutine  is  executing  (i.e.,  values  are  not 
necessarily  preserved  between  calls).  Automatic  is  the  default 

allocation  for  data  declared  in  subroutines  and  cannot  be  explicitly 
specified.  STATIC  is  the  default  for  data  not  declared  in  subroutines 
and  can  be  explicitly  specified  both  inside  and  outside  of  subroutines. 

The  treatment  of  STATIC  data  in  a  concurrent  processing  environment 
is  implementation-dependent  with  respect  to  which  data,  if  any,  are 
shared  among  processes* 

2.1.6  INITIALIZATION  OF  DATA  OBJECTS 
Syntax: 

<item-preset>  “  <item-preset-value> 

<item-preset-value>  :  :*  <compile-time--formula> 

I  <loc-function> 

<table-preset>  : :»  "  <table-preset-list> 

<table-preset-list>  :  :*  <default-preset-sublist> 

|  [<default-preset-sublist>  ,] 

<specif ied-preset-sublist> , . . . 

<def ault-preset-sublist>  : <preset-values-option> , . . . 

<specified-preset- 

sublist>  : :»  <preset-index-specif ier> 

<preset-values-option> , . . . 

<preset-index-specif ier>  POS  (  <constant-index>, . . .  )  : 

<constant-lndex>  <compile-time-integer-formula>  (5.1.1) 

|  <compile-time-status-formula>  (5.4) 

<preset-values-option>  [<item-preset-value>] 

1  <repetition-count> 

(  <preset-values-option>, ...  ) 


(5.0) 

(6.3.1) 


<repetition-count> 


<compile-time-integer-f ormula>  (5.1.1) 
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<block-preset>  :  :■ 

<block-preset-list>  : :■ 

<block-preset-values-  : :« 

option> 

I 

I 

Semantics : 


■  <block-preset-list> 
<block-preset-values-option> , * . . 
<preset-values-option> 

((  <table-preset-list>  )] 

[(  <block-preset-list>  )] 


Items,  tables,  and  blocks  with  STATIC  allocation  can  be  given 
initial  values  by  means  of  <ltea-presets>,  <table-presets>,  and 
<block-presets>,  respectively.  Furthermore,  constant  items  and  cables 
must  be  given  initial  values  with  <item-presets>  and  <table-presets> . 
Initial  values  are  values  of  the  variables  after  a  module  has  been 
loaded  but  prior  to  any  dynamic  reference  to  the  variables.  They  do  not 
imply  any  provision  for  later  restoring  values  to  the  initial  state. 


An  <item-preset>  specifies  an  Initial  value  for  an  item. 


A  <table-preset>  specifies  a  list  of  initial  values.  If  the 
<table-preset>  occurs  on  an  item  within  an  entry  of  a  table,  the 
<table-preset>  specifies  values  only  for  that  item.  If  the  table  is 
dimensioned,  the  <table-preset>  for  the  item,  if  present,  may  specify  a 
list  of  values  to  initialize  chat  item  in  each  entry  of  the  dimensioned 
Cable. 


If  Che  <table-preset>  occurs  on  an  entry  of  a  table,  the 
<table-preset>  specifies  values  for  all  items  within  that  entry.  If  the 
table  is  dimensioned,  the  <table-preset>  specifies  values  for  all  the 
items  in  each  entry  of  the  dimensioned  cable.  Assuming  Che  entry  has  N 
items  in  it,  the  first  N  values  in  the  <table-preset>  are  initial  values 
for  the  N  items  in  the  first  entry  of  the  table  (in  the  order  in  which 
the  declarations  appear),  the  second  N  values  in  the  <table-preset>  are 
initial  values  for  the  N  items  in  the  second  entry  of  the  table,  etc. 

Entries  within  a  dimensioned  table  are  normally  initialized  in 
order,  the  first  entry  being  the  one  with  the  lowest  value  of  each 
dimension  index,  and  proceeding  with  Che  rightmost  indices  increasing 
most  rapidly.  This  is  the  procedure  followed  when  a  <def ault-preset- 
sublist>  is  specified.  If  a  <specif ied-preset-sublist>  is  used, 
initialization  using  the  values  in  the  sublist  will  start  with  Che  entry 
whose  indices  are  specified  in  the  <preset-index-specifier>  and  will 
proceed  with  the  rightmost  indices  increasing  most  rapidly. 

A  <repetition-count>  can  be  used  as  a  shorthand  to  specify  the 
number  of  consecutive  repetitions  of  the  sequence  of  <preset-values- 
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opcions>  enclosed  In  che  parentheses  following  Che  <repetltlon-count>. 

If  a  value  is  omicted  in  Che  <table-preset>,  che  itea  corresponding 
to  che  omicted  value  will  remain  uninitialized  and  cannot  be  given  an 
inicial  value  elsewhere  in  che  preset. 

A  <block-preset>  is  used  only  to  initialize  a  block  declared  with  a 
Olock-type-name> .  The  <block-preset-list>  specifies  inicial  values  for 
Che  items,  Cables  and  blocks  contained  within  Che  block  in  che  order  of 
their  declaration.  A  parenthesized  <table-preset-list>  is  used  Co 
iniclalize  a  contained  cable  and  a  parenthesized  <block-preset-list>  is 
used  to  initialize  a  contained  block.  An  omicted  entry  from  the  list 
indicates  that  the  cbrresponding  item,  table,  or  block  will  remain 
uninitialized. 

Constraints: 

The  type  of  each  value  in  an  <item-preset>,  <table-preset>  or 
<block-presec>  must  match  or  be  implicitly  convertible  to  the  type  of 
che  data  object  being  initialized  (see  Section  7.0). 

The  <preset-index-specifiers>  within  a  <table-preset>  must  be 
specified  such  that  no  bit  position  is  initialized  more  than  once  and 
the  bounds  of  the  table  are  not  exceeded. 

The  value  of  the  <repetition-count>  must  not  be  negative. 

An  item  must  not;  be  initialized  more  than  once  by  initializing 
another  item  that  overlaps  it. 

The  type  of  each  <constant-index>  in  a  <preset-index-specifier> 
must  match  the  type  of  the  bounds  of  the  corresponding  dimension  in  the 
<dimension— list>  of  che  declaration  of  the  cable. 

The  number  of  <constant-indices>  in  a  <preset-index-specifier>  must 
be  the  same  as  the  number  of  <dimensions>  in  the  Cable's 
<dimension-list>. 

If  the  argument  of  a  <loc-function>  used  as  a  preset  value  is  a 
<named-variable> ,  it  must  be  a  <data-name>  for  an  object  whose 
allocation  permanence  is  STATIC,  either  explicitly  or  by  default. 
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2.2  TYPE  DECLARATIONS 

Syntax: 

<type-declaratlon> 

•  •  « 

•  • 

<i tem-type-declaration> 

1 

1 

<table-type-declaration> 

<block-type-declaration> 

<item-type-declaration> 

: :» 

TYPE  <item-type-name> 
<item-type-description>  ; 

(2.1.1) 

<i tem-type-name> 

*  •  SB 

•  e 

<name> 

(8.2.1) 

<  table- type-decla  ra  t i on> 

•  e » 

•  • 

TYPE  <table-type-name> 

TABLE  <table-type-specifier> 

<table-type-specifier> 

{ <dimension-list> ] 
[<structure-specifier>] 
I<like-option>] 
<entry-specifier> 

(2. 1.2.1) 
(2. 1.2.2) 

(2.1.2) 

1 

[<dimension-list>J 
<table-type-name>  ; 

(2. 1.2.1) 

<  t  abl  e- 1  y  pe-name> 

:  :•» 

<name> 

(8.2.1) 

<like-option> 

•  •  « 

• 

LIKE  <table-type-name> 

<block-type-declaration> 

•  •* 

TYPE  <block-type-name> 

BLOCK  <block-body-part> 

(2.1.4) 

<block-type-name> 

Semantics: 

:  :■ 

<name> 

(8.2.1) 

A  <type-declavation> 

is 

used  to  give  a  name  tc 

»  a  type 

specification. 

An  <item-type-declaration>  associates  the  <item-type-name>  with  the 
<item-type-description> . 

A  <table-type-declaration>  associates  the  <table-type-name>  with 
the  <table-type-specifier>. 

If  a  <like-option>  is  specified,  the  entry  being  described  consists 
of  the  iteas  in  the  type  named  in  the  <like-option>  together  with  the 
items  in  the  <entry-specif ier> .  The  physical  positioning  of  items  in 
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che  <like-optloa>  relative  Co  Che  stare  of  the  entry  Is  fixed  at  the 
time  the  <llke~option>  type  name  is  declared  and  is  not  changed  by  its 
use  as  a  <llke-optlon>.  If  the  type  named  in  the  <like-option>  contains 
a  <dimension-specifier>,  it  applies  to  the  entire  <table-type- 
specifier>.  If  the  table  is  an  ordinary  table,  the  <packing-spedfier>, 
if  present,  only  applies  to  the  items  in  the  <entry-specif ier>,  not  to 
the  items  obtained  from  the  <llke-optlon>*  If  the  table  is  a  specified 
table,  the  <words-per-entry>  in  the  <entry-specifier>,  if  present, 
specifies  the  total  size  of  the  entry  including  the  Items  obtained  from 
the  <like-option> .  If  the  <table-type-declaratlon>  contains  a 
<structure-specif ier>  of  T,  <bits-per-entry>  specifies  the  total  number 
of  bits  the  entry  is  to  occupy  including  items  obtained  from  the 
<like-option>.  If  <bits-per-entry>  is  omitted  it  will  default  to  the 
minimum  number  of  bits  needed  to  store  the  entry,  including  items 
obtained  from  the  <1 ike-op tion>. 

The  physical  representation  of  a  table  type  is  fixed  by  the  type 
declaration.  All  objects  allocated  with  such  a  type  name  will  have  the 
same  representation.  In  particular,  the  position  of  table  Items  In  a 
<like-option>  is  not  modified  by  the  occurrence  of  a  <packing-specifier> 
or  <order-directive>  in  Che  <entry-specifier>.  However,  unused  space  in 
the  portion  described  by  the  <like-option>  can  be  occupied  by  table 
items  given  in  a  packed  <entry-specifier>. 

A  <block-type-declaration>  associates  the  <block-type-name>  with 
the  <block-body-part>. 

For  type  matching  purposes,  a  type  name  is  considered  to  be  an 
abbreviation  for  its  associated  <item-type-description> , 
<table-type-specifier>,  or  <block-body-part> ,  in  any  context  except 
within  a  <pointer-item-description>. 

Constraints: 

The  <item-type-description>,  <table-type-specifier>,  or  <block- 
body-part>  in  a  <type-declarstion>  must  not  contain  an  <item-preset>, 
<table-preset>,  or  <block-preset> . 

A  <block-body-part>  in  a  <block-type-declaration>  cannot  contain 
<constant-declarations>. 

If  a  <table-type-specifier>  contains  a  <dimension-list>,  then  it 
must  not  contain  a  <table-type-name>  (either  directly  or  in  a  <like- 
option»  whose  <table-type-declaration>  contains  a  <dlmension-list>. 

Tables  may  be  characterized  as  parallel,  serial,  tight,  ordinary, 
variable-length-entry,  and  specified.  The  characterizations  of  the 
table  type  in  a  <like-option>  must  be  the  same  as  those  of  the 
<table-type-declaration>  in  which  the  <llke-optlon>  appears. 
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<Vords-per-entry>  of  the  <table-type-specifier>  must  not  specify  a 
value  that  is  less  than  <words-per-entry>  of  the  type  name  specified  in 
a  <like-option>. 

The  (explicit  or  default)  number  of  bits  per  entry  in  a 
<table-type-specif ier>  having  tight  structure  must  not  be  less  than  the 
number  of  bits  per  entry  of  the  type  name  specified  in  a  <like-option>. 

A  <table-type-name>  must  be  a  <name>  declared  in  a 

<table-type-declaration> . 

A  <block-type-name>  must  be  a  <name>  declared  in  a 
<block-type-declaration> . 

Note; 

A  <table-type-name> ,  <item-type-name> ,  or  <block-type-name>  must 
not  be  a  formal  parameter  name  or  an  actual  parameter  name. 


2.3  STATEMENT  NAME  DECLARATIONS 
Syntax; 

<statement-name-declaration>  ; :•  LABEL 

<statement-name>,...  ;  (4.0) 


Semantics; 

A  <statement-name-declaration>  is  used  to  explicitly  declare  a 
<statement-name> .  Ordinarily ,u a  <statement-name>  is  implicitly  declared 
by  its  use  in  a  <label>.  An  explicit  <statement-name-declaration> , 
however,  must  be  used  for  statement  name  <formal-input-parameters> ,  for 
statement  names  that  are  the  same  as  <def ine-names>  declared  in  an 
enclosing  scope,  and  for  external  <statement-name-declarations>. 

Constraints; 

The  <statement-names>  in  a  <statement-name-declaration>  must  either 
be  <formal-input-parameters>  to  the  subroutine  containing  the 
<statement-name-declaration>  or  else  must  be  used  in  <labels>  in  the 
immediate  scope  containing  the  <statement-name-declaration>  (i.e.,  not 
including  nested  scopes). 
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2.4  DEFINE  DECLARATIONS 

Syntax: 

<def ine-dec la ra t ion> 

•  •  m 

•  • 

DEFINE  <def ine-name> 
<definition-part> 

<define-name> 

•  « 

•  • 

<name> 

(8.2. 

<definition-part> 

[<formal-define-parameter-li8t>] 
<define-string>  ; 

<formal-def ine-parameter- 
-list> 

:  :■ 

(  <formal-define-parameter> , . .. 

) 

<f  o rmal-def ine-pa rame  t  e  r> 

:  :■ 

<letter> 

V 

(8.1) 

<def ine~string> 

"  [<character>. . .]  " 

(8.1) 

Semantics : 

A  <def lne-declaration>  is  used  to  associate  a  name  with  a  (possibly 
parameterized)  text  string,  the  <def ine-string>.  The  <de£ ine-string> 
will  be  substituted  for  the  <def ine-name>  when  the  <def ine-name>  is  used 
in  a  <define-call>  (see  Section  2.4.1). 

The  <formal-def ine-parameter-list>  is  used  to  declare 
<formal~def ine-parameters>.  These  parameters  receive  values  from 
<actual-def ine-parameters>  in  each  <def ine-call>  (see  Section  2.4.1). 
The  values  are  substituted  in  the  <def ine-string>  wherever  the 
<formal-define-parameters>  are  referenced.  Reference  to  a 
<fonnal-define-parameter>  within  the  <def ine-string>  is  indicated  by 
preceding  the  parameter  name  with  an  exclamation  point.  Such  parameter 
references  can  occur  anywhere  within  the  <def ine-*string>  and,  by 
appropriate  juxtaposition,  can  be  used  to  create  new  symbols. 

Within  the  <define-string>,  the  quotation  mark  (")  and  exclamation 
point  (!)  can  be  used  as  simple  characters  by  doubling  them.  A 
<define-strlng>  is  terminated  by  the  first  undoubled  quotation  mark, 
regardless  of  the  lexical  context  in  which  the  undoubled  quotation  mark 
appears. 

As  with  other  <names>,  a  <define-name>  is  known  in  the  scope 
containing  its  declaration  and  may  be  redeclared  in  an  inner  scope. 

The  <deflne-strlng>  may  contain  <define-calls>.  Such  calls  will  be 
expanded  for  each  substitution  of  the  <def ine-string>,  using  the 
definition  active  in  the  scope  of  the  <deflne-call>. 
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Constraints : 

A  <comment>  delimited  by  quotation  marks  must  not  occur  in  a 
<deflne-declaratlon>  between  the  <de£ine-name>  and  the  <def ine-string>. 

Circular  <def lne-declarations>  as  the  result  of  <def ine-strings> 
containing  <def ine-calls>  are  not  allowed. 

The  same  <letter>  must  not  appear  more  than  once  in  any 
<f ormal-def ine—pa rame  t e  r-lis  t> . 

2.4.1  DEFINE  CALLS 

Syntax; 

<define-call> 

<ac tual-def ine-parame  ter- 

nst> 

<ac tual-def 1 ne-pa  rame  t  e  r> 


<def ine— name>  (2.4) 

[<actual-define-parameter-list>] 

:  (  <actual-define-parameter>, .. .  ) 

:  [  <character>. . .  ]  (8.1) 

I  "  [<character>. ..]  "  (8.1) 


Semantics; 

A  <define-call>  is  used  to  cause  textual  substitution  to  occur.  A 
<def ine-call>  is  processed  as  follows: 

1.  The  characters  comprising  <actual-define-parameters>  are 

substituted  for  the  corresponding  <formal-define-parameters> 
in  the  <def ine-string>  associated  with  the  <def ine-name>. 

2.  The  resulting  <def ine-string>  logically  replaces  the 

<def ine-call> . 

3.  The  substituted  <def ine-string>  is  scanned  from  its  beginning 
to  determine  what  <symbols>  it  contains;  these  <symbols>  are 
processed  as  though  they  had  appeared  in  the  orginal  text  at 
the  point  of  the  replaced  <def ine-call> . 

Note  that  the  substituted  source  text  may  be  found  to  contain 
<def ine-calls>  and  these  are  processed  in  the  same  manner. 

If  an  <actual-define-parameter>  is  omitted,  a  null  string  will  be 
substituted  for  the  <f ormal-def ine-parame ter>.  If  the  number  of 
<formal-define-parameters>  exceeds  the  number  of 

<actual-define-parameters>,  null  strings  will  be  substituted  for  the 
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trailing  <formal-define-parameters>. 

If  an  <actual-def ine-parameter)  consists  of  characters  enclosed  in 
quotation  marks,  all  the  enclosed  characters  are  substituted.  The 
quotation  mark  (")  must  be  doubled  within  an  actual  parameter  enclosed 
in  quotes. 

If  an  <actual-def ine-parameter)  does  not  contain  enclosing 
quotation  marks,  the  characters  substituted  are  the  first  non-blank 
character  and  subsequent  characters  ending  at,  but  not  Including,  either 
(1)  the  first  right  parenthesis  that  is  not  balanced  by  a  left 
parenthesis  that  is  part  of  the  <actual-def ine-parameter),  or  (2)  the 
first  comma  that  is  not  between  such  balanced  parentheses. 

<Def ine-calls>  are  not  recognized  in  <comments>  and  <character- 
literals>. 

Constraints: 

The  <actual-def ine-parameter-list>  must  not  be  omitted  if  the 
corresponding  <def ine-declaration>  contains  a  <formal-def ine-parameter- 
11st) . 


The  number  of  <actual-def ine-parameters>  must  not  be  greater  than 
the  corresponding  number  of  <formal-def ine-parameters>. 

A  <define-call>  cannot  be  juxtaposed  with  surrounding  symbols  so  as 
to  create  new  symbols  after  substitution. 

A  <def ine-call)  must  not  be  used  as  the  <name>  being  declared 
within  a  declaration. 

A  <def ine-call)  must  not  be  used  as  a  <formal-input-parameter>  or 
<formal-output-parameter>  within  a  <procedure-heading>  or  function- 
heading). 

The  same  fetter)  must  not  appear  more  than  once  in  any 
<formal-define-parameter-list>. 

Note: 

The  def ine-listing  directives  (see  Section  9.7.2)  allow  programmer 
control  over  whether  the  source  program  listing  contains  the  expanded 
string,  the  define  invocation,  or  both,  for  <def ine-calls). 

Examples: 

DEFINE  F00(A)  "BAZ  IAFAZ  ! A”; 

DEFINE  BAR  "HELLO"; 
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DEFINE  BARFAZ  "GOODBYE”; 

DEFINE  HELLO FAZ  "NOT  USED"; 

FOO(BAR) 

The  result  of  the  <def ine-call> ,  FOO(BAR),  after  substituting  for  the 
formal  parameter  !A  is  BAZ  BARFAZ  BAR,  and  after  rescanning  this  string, 
the  final  result  is  BAZ  GOODBYE  HELLO. 

DEFINE  MAKEDEF(N,  S)  "DEFINE  !N  ••"IS"""; 

MAKEDEF(NEW,  HELLO); 

The  result  is  DEFINE  NEW  "HELLO";  ,  i.e.,  a  new  <def ine-dedaration> . 

2.5  EXTERNAL  DECLARATIONS 
Syntax: 

<external-dedaration>  <def-specif  ication>  (2.5.1) 

|  <ref-speclfication>  (2.5.2) 

Semantics: 

<External-declarations>  declare  <names>  that  are  potentially  known 
in  other  <modules>  of  the  <complete~program>.  Such  names  are  said  to  be 
external . 

Constraint: 

Formal  parameter  names  cannot  be  declared  external. 

2.5.1  DEF  SPECIFICATIONS 
Syntax: 

<def-specif ication> 

<simple-def> 


<compound-def> 


:  :■  <simple-def> 

|  <compound-def> 

:  :■  DEF 

<def-specification-choice> 

DEF  SEGIN 

<def-  pecif ication-choice>. .. 
END 
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<def-speciflcatlon-choice>  <null-declaration>  (2.7) 

I  <daca-declaratlon>  (2.1) 

I  <def-block-instantiation> 

|  <statement-name— declaratlon>  (2.3) 

I  <dlrecdve>  (9.0) 

<def-speciflcation-choice> 

<def-block-instantiation>  :  :■  BLOCK  INSTANCE 

<block-naoe>  ;  (2.1.4) 

Semantics: 

<Def-speclficatlons>  enable  data  objects  to  be  declared  that  are 
potentially  available  via  <ref-speciflcations>  and/or  <compool- 
dlrectives>  for  use  In  other  <modules>.  Physical  storage  will  be 
allocated  for  these  objects. 

Either  a  <def-block-instantiatlon>  or  a  <block-dedaratlon>  may  be 
used  in  a  <def-specif lcation>  to  create  a  block  with  external  scope. 
However,  in  order  for  a  <def-block-instantiation>  to  be  meaningful,  a 
<ref-specification>  containing  a  <block-declaration>  having  the  same 
<block-name>  must  exist,  either  In  that  <module>  or  In  a 

<compool-module>  that  is  referenced  via  a  <compool— directive> .  Preset 
Information  used  In  the  creation  of  a  block  declared  with  a 

<def-block-instantiation>  will  be  obtained  from  the  corresponding 
<ref-specif ication> . 

A  <statement-name-declaration>  in  a  <def-speclflcation>  makes  the 
addresses  of  the  designated  statements  available  as  linkage  information 
In  the  environment  of  the  <complete-program>  but  does  not  make  these 
names  available  as  targets  of  out-of-scope  GOTO  statements  (see  Section 
4.7). 

Constraints : 

A  data  declaration  in  a  <def-speciflcatlon>  and  a  corresponding 
declaration  in  a  <ref-specif ication>  must  agree  in  name,  type,  and  all 
attributes.  However,  a  compiler  will  perform  this  check  across  <module> 
boundaries  only  if  a  connection  is  established  between  the  <modules>  via 
a  <compool-directive>. 

External  data  must  have  STATIC  allocation,  either  explicitly  or 
implicitly. 
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The  <data-declaratlon>  in  a  <def-specif ication>  cannot  be  a 
<conatant-declaratlon>.  (This  constraint  does  not  prevent  <constant- 
dedarations>  from  appearing  in  <block.-dedaratlons>  in  <def- 
specif lea tlons>.) 


2.5.2  REF  SPECIFICATIONS 
Syntax: 

<ref -specification  :  :■  <slnple-ref> 

I  <compound-ref> 

<simple-ref>  : REF 

<ref-specification-choice> 

<compound-ref>  : :■  REF  BEGIN 

<ref-speclficatlon-choice>. .. 


END  , 

<ref-specificatlon-choice>  <null-declaration>  (2.7) 

i  <da ta-declara  t lon>  (2.1) 

|  <subroutine-dedaratlon>  (3.0) 

|  <directive>  (9.0) 


<ref-specification-choice> 

|  <statement-name-declaration>  (2.3) 

Semantics:  »» 

A  <ref-specif ication>  enables  a  <module>  to  reference  a  <name> 
whose  <def-specification>  is  in  another  <modde>. 

Physical  storage  for  external  names  occurs  in  Che  <module> 
containing  the  <def-specif icatlon>  and  not  in  the  <module>  containing 
the  <ref-specification> . 

A  <ref-specification>  for  a  <name>  may  appear  in  a  <compool-module> 
and  the  corresponding  DEF  in  another  <module>.  In  Chat  case,  the  <name> 
will  be  available  for  use  in  any  other  module  of  the  <complete-program>, 
provided  that  the  referencing  module  has  the  appropriate 
<compool-dlrectlve>.  The  compiler  will  enforce  the  requirement  that  the 
DEF  and  the  REF  specifications  agree,  provided  the  <module>  containing 
the  DEF  has  the  appropriate  <compool-dlrectlve>.  Alternatively,  the 
<ref-specif ication>  may  appear  in  Che  accessing  <module>  directly 
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instead  of  in  a  compool  (bypeasing  the  compool  entirely),  but  in  this 
case  it  will  be  beyond  the  coapller's  ability  to  check  for  compatibility 
between  the  DEF  and  the  REF  specifications*  When  <ref-specifications> 
are  used  outside  of  compools  to  gain  access  to  external  names,  the 
programmer  is  entirely  responsible  for  the  correct  usage  of  those  names. 

For  <data-declarations>  in  a  <def-specif ication>  that  is  in  a 
<compool-module>,  no  <ref-speciflcatlon>  is  necessary  if  the  accessing 
module  has  a  <compool-directlve>  that  causes  that  data  to  be  imported 
(see  Section  9.1). 

Constraints: 

For  every  <data-declaratlon>  in  a  <ref-specificatlon>,  there  must 
exist  a  corresponding  declaration  in  a  <def-speclficatlon>.  For  every 
<subroutlne-dedaratlon>  in  a  <ref-speclflcatlon>,  there  must  exist  in 
some  <procedure~module>  or  <maln-prograa-module>  a  corresponding 
<procedure-definition>  preceded  by  DEF. 

In  *  a  <ref-specification>,  presets  are  illegal  in 
<item-declarations>  and  <table-deciaratlons>  and  are  optional  in 
<block-*dedarations>  .  A  <ref-speclf ication>  that  contains  presets  can 
be  used  only  in  conjunction  with  a  <def-block-instantiation> . 

A  <data-dedaration>  in  a  <ref-specif  ication>  cannot  be  a 
<constant-declaration>.  (This  constraint  does  not  prevent 
<constant-dedaratlons>  from  appearing  in  <  block-dec  la  rations>  in 
<ref-specif ications» . 


2.6  OVERLAY  DECLARATIONS 
Syntax: 

<overlay-declaration> 


<absolute-address> 
<ovexlay-address> 
<overlay-expression> 
<ove rlay- s t r ing> 
<overlay-element> 


: :-  OVERLAY 

[ <absolute-address> ] 

<overlay-expression>  ; 

POS  (  <overlay-address>  )  : 

:  <compile-time-integer-formula>  (5.1.1) 

::-  <overlay-string>: ... 

<overlay-element>, ... 

:  :■  <spacer> 
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<spacer> 

<data-name> 


Semantics : 


I 


I 

t 


<data-name> 

(  <overlay-expression>  ) 

W  <compile-tlme-lnteger-f ormula>  (5.1*1) 


<item-name> 

<table-name> 

<block-name> 


(2.1.1) 
(2.1.2) 
' (2.1.4) 


An  <overlay-declaration>  Is  used  to  specify  any  or  all  of  the 
following: 

1)  that  data  objects  are  to  have  a  specific  allocation  order 

2)  that  certain  data  objects  are  to  occupy  the  same  memory 
locations  as  other  data  objects 

3)  that  certain  data  objects  are  to  be  allocated  at  a  particular 
absolute  memory  location 

The  <overlay-elements>  in  an  <overlay-strlng>  are  allocated  memory 
locations  in  the  order  of  their  appearance  in  the  string.  The  memory 
locations  allocated  to  the  elements  of  an  <overlay-strlng>  that  appears 
to  the  left  of  a  colon  in  an  <overlay-expression>  are  overlayed  with  the 
space  allocated  to  the  elements  of  the  <overlay-string>  that  appears  to 
the  right  of  the  colon. 

The  <overlay-address>  specifies  an  absolute  memory  location  at 
which  allocation  of  the  <overlay-expression>  begins.  The  meaning  of  an 
overlay  address  is  machine  dependent. 


A  <spacer>  in  an  <overlay-string>  specifies  a  number  of  words  to  be 
skipped  during  allocation. 


Constraints : 

The  allocation  permanence  of  all  data  objects  in  an 
<overlay-declaration>  must  be  the  same  (i.e.,  all  STATIC  or  all 
automatic). 

An  <overlay-declaration>  within  a  <block-declaration>  or 
<block-type-deelaratlon>  must  not  reference  data  names  declared  outside 
the  block  or  block  type  or  within  nested  blocks. 
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An  <overlay-declaration>  outside  a  <block-dedaration>  or 

<block-type-declaratlon>  must  not  reference  data  names  declared  within  a 
block  or  block  type. 

An  <overlay-dedaratlon>  within  a  <block-declaratlon>  or 

<block-type-dedaration>  must  not  include  an  <absolute-address>* 

A  <block-declaration>  or  <block-type-declaratlon>  must  not  include 
an  <overlay-~declaratlon>  if  an  <order-dlrective>  is  in  effect  for  the 
block  or  block  type. 

Declarations  for  all  <data-names>  in  an  <overlay-declaration>  must 
precede  the  <overlay-declaratlon>,  and  all  must  be  in  the  same  scope. 

<Overlay-dedaratlons>  cannot  be  used  to  specify  more  than  one 
physical  location  to  any  data  object. 

Names  of  formal  parameters  cannot  be  used  in 
<overlay-declarations> . 

If  an  <overlay-address>  is  specified,  all  <data~names>  used  in  the 
<overlay— express Ion>  must  have  an  (explicit  or  default)  allocation 
permanence  of  STATIC. 

Note: 


A  <data-name>  in  an  <overlay-declaration>  cannot  be  declared  in  a 
<constant-declaration>. 


2.7  NULL  DECLARATIONS 
Syntax: 

<null-declaration>  : ; 

|  BEGIN  END 


Semantics: 


A  <null-declaration>  has  no  semantic  effect 
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3.0  PROCEDURES  AND  FUNCTIONS 
Syntax: 

<subroutlne-declaration>  : <procedure-declaration>  (3.1) 

I  <function-declaration>  (3.2) 

<subroutine-def lnition>  <procedure-definition>  (3.1) 

|  <function-def inltion>  (3.2) 

|  <directive>  (9.0) 

<subroutine-definition> 

Semantics: 


Subroutines  describe  algorithms  that  may  be  executed  from  more  than 
one  place  In  a  <complete-program>.  A  subroutine  is  either  a  procedure, 
which  is  Invoked  by  a  <procedure-call-statement> ,  or  a  function,  which 
Is  invoked  by  a  <function-call>. 

A  <subroutine-def inition>  contains  the  executable  code  for  the 
subroutine,  in  addition  to  declarations  for  all  local  data  and  formal 
parameters,  as  well  as  definitions  of  any  nested  subroutines.  A 
<subroutlne-definitlon>  is  said  to  define  the  subroutine. 

A  <subroutlne-declaratlon> ,  on  the  other  hand,  is  said  to  declare 
the  subroutine.  A  <subroutine-declaration>  contains  the  heading  of  the 
subroutine  and  <declaratlons>  for  the  formal  parameters,  but  it  contains 
no  executable  code.  A  <subroutine-declaration>  is  required  in  a 
<ref-specif ication>  for  each  subroutine  that  is  invoked  in  a  module 
other  than  the  module  containing  its  definition  (see  Section  2.5).  A 
<subroutine-declaratlon>  is  also  required  in  two  other  situations:  (1) 
when  a  subroutine  name  is  declared  as  a  formal  parameter  (see  Section 
3.3),  i  and  (2)  when  the  name  of  the  subroutine  is  the  same  as  a 
<define-name>  in  an  enclosing  scope.  It  is  not  necessary  to  provide  a 
<subroutine-declaratlon>  if  the  subroutine  is  invoked  only  in  the 
<module>  where  it  is  defined  and  if  its  name  is  not  passed  as  a 
parameter  or  used  in  an  enclosing  scope  as  a  <define-name>. 

Constraints: 

The  <procedure-heading>  or  <functlon-headlng>  of  a  Subroutine- 
declaration^  and  that  of  the  corresponding  <subroutine-definition>  must 
have  identical  attributes,  and  the  parameters  (both  input  and  output) 
must  agree  in  number,  type,  and  order.  (This  constraint  will  be 
enforced  only  when  the  declaration  is  known  in  the  scope  of  the 
definition.)  Also,  the  subroutine  name  in  the  declaration  and 
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definition  oust  be  the  same  (unless  the  <subroutlne-declaratlon>  is  for 
a  formal  parameter). 


3.1  PROCEDURES 


Syntax: 


<procedure-declaration> 

•  2  ® 

<procedure-heading>  ; 
<declaratlon> 

(2.0) 

<procedure— def inition> 

*  *  t 

•  • 

<procedure-heading>  ; 

[<dlrective>...] 

<procedure-body> 

(9.0) 

<procedure-headlng> 

•  V* 

PROC 

<procedure-name> 

{ < su b r ou t i ne-a t t r ibu t e> ] 

[ <f ormal-parameter-lis t> ] 

(3.3) 

<subroutine-attrlbute> 

* 

•  • 

REC 

1 

RENT 

<procedure-name> 

•  ••m 

•  • 

<name> 

(8.2.1) 

<procedure-body> 

: :» 

<subrouti ne-body> 

<subroutine-body> 

*  •  m 

•  • 

<statement> 

(4.0) 

1 

BEGIN  [<declaratlon>...] 
<statement> . . . 

[<subroutine-def inition> . . . ] 
[<directlve> ...  I 
[<label>. ..]  END 

(2.0) 

(4.0) 

(3.0) 

(9.0) 

(4.0) 

Semantics: 


The  <procedure-headlng>  in  a  <procedure-declaration>  may  contain  a 
<formal-parameter-list>,  which  specifies  the  names  that  are  used  in  Che 
<procedure-body>  to  refer  to  the  corresponding  arguments  supplied  by 
each  call  of  the  procedure.  The  syntax,  semantics,  and  constraints  for 
a  procedure's  <formal-parameter-list>  are  the  same  as  for  a  function's 
<formal-parameter-list>,  and  are  presented  in  Section  3.3. 

The  differences  between  a  <procedure-declaration>  and  a 
<procedure-def lnitlon>  are  described  in  Section  3.0. 

A  <subroutine-attribute>  of  REC  indicates  chat  the  subroutine  is 
potentially  recursive,  i.e.,  that  at  run  time,  an  invocation  of  the 
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subroutine  ney  be  dynamically  nested  within  another  Invocation  of  it* 
If  REC  is  present ,  physical  allocation  of  locally-declared  automatic 
data  will  occur  dynamically.  The  data  will  be  allocated  and  deallocated 
when  the  subroutine  is  entered  and  exited,  respectively.  This  assures 
that  separate  copies  of  the  local  data  will  exist  for  each  successive 
call  in  the  recursive  chain.  Locally-declared  STATIC  data,  however, 
will  be  allocated  once,  and  the  same  storage  will  be  used  for  all  calls 
of  that  subroutine  throughout  the  <complete-program>. 

A  <subroutine-attrlbute>  of  RENT  indicates  that  the  subroutine  is 
re-entrant  and  may  therefore  be  executed  concurrently  in  a  concurrent 
processing  environment.  A  recursive  subroutine  is  also  re-entrant. 

If  execution  of  the  <procedure-body>  is  completed  without  executing 
a  RETURN  statement,  an  ABORT  statement,  or  a  GOTO  statement  whose  target 
is  the  name  of  a  formal  parameter,  an  implicit  RETURN  statement  is 
executed. 

Constraints: 

A  <procedure-decla ration!  can  contain  no  <declarations>  other  than 
those  for  the  procedure's  formal  parameters.  <Declarations>  of  local 
data  appear  only  in  the  procedure's  definition. 

A  procedure  must  not  be  invoked  recursively  if  It  is  not  declared 

REC. 


A  procedure  must  not  be  invoked  re-entrantly  if  it  is  not  declared 
RENT  or  REC. 

A  <subroutine-body>  must  contain  at  least  one  non-null  <statement> 
(e.g.,  RETURN). 


3.2  FUNCTIONS 


Syntax: 


<function-declaration> 

:  :*  <function-heading>  ; 

<declaration> 

(2.0) 

<f unction-def ini tion> 

:  <function-heading>  ; 

[<directive>...] 

<function-body> 

(9.0) 

<function-heading> 

::■  PROC  <function-name> 

[<subroutine-attribute>] 

(3.1) 

[<formal-parameter-list>] 

(3.3) 

<item-type-description> 

(2.1.1) 
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<functlon-name>  <name>  (8.2.1) 

<funetlon-body>  < subrout ine-body>  (3.1) 

Senantlcsi 

The  differences  between  a  <function-declaration>  and  a 

<function-definltion>  are  described  in  Section  3.0. 

The  <lteD-type-descrlption>  specifies  the  type  of  the  return  value 
of  the  function.  Within  the  body  of  the  function,  the  name  of  the 
function  may  be  assigned  to  as  a  variable  in  an  assignment  statement. 
When  the  function  is  exited,  the  most  recent  value  assigned  to  the 
<functlon-name>  is  used  as  the  value  of  the  function.  The  return  value 
is  considered  to  be  allocated  as  automatic  storage  (see  Section  2.1.5). 

Use  of  the  <functlon-name>  in  a  <formula>  within  the  body  of  the 
function  is  a  recursive  invocation  of  the  function.  Within  the  body  of 
the  function,  the  <function-name>  may  also  be  used  as  an 
<aetual-lnput~parameter>  in  a  subroutine  call  when  the  corresponding 
<formal-input-parameter>  is  a  <functlon-name>  (see  Section  3.3). 

The  <functlon-heading>  in  a  <function-declaratlon>  or  <function- 
definltion>  may  contain  a  <formal-parameter-list> ,  which  specifies  the 
names  that  are  used  in  the  <function-body>  to  refer  to  the  corresponding 
arguments  supplied  by  each  call  of  the  function.  The  syntax,  semantics, 
and  constraints  for  a  function's  <formal-parameter-list>  are  the  same  as 
for  a  procedure's  <formal-parameter-list>,  and  are  presented  in  Section 
3.3. 


The  inclusion  of  an  <item-type-description>  in  the  heading  of  a 
subroutine  indicates  that  the  subroutine  is  a  function. 

The  <subroutlne-attrlbutes>  of  REC  and  RENT  apply  to  functions  in 
the  same  way  as  for  procedures  (see  Section  3.1). 

If  execution  of  the  <functlon-body>  is  completed  without  executing 
a  RETURN  statement,  an  ABORT  statement,  or  a  GOTO  statement  whose  target 
is  the  name  of  a  formal  parameter,  an  implicit  RETURN  statement  is 
executed. 

Constraints : 

The  <functlon-name>  may  not  be  used  as  an 
<actual-output-parameter> . 

The  <function-name>  is  not  declarable  as  a  <name>  within  the 
function  body. 
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A  <function-declaration>  can  contain  no  <declaratlons>  other  than 
those  for  the  functions  formal  parameters.  <Declarations>  of  local  data 
appear  only  In  the  function's  definition. 

A  function  must  not  be  Invoked  recursively  if  it  is  not  declared 

REC. 

A  function  must  not  be  invoked  re-entrantly  if  it  Is  not  declared 
RENT  or  REC. 

The  <functlon-name>  must  be  assigned  a  value  before  the  function  is 
exited. 

3.3  PARAMETERS  OF  PROCEDURES  AND  FUNCTIONS 
Syntax; 


<formal-parameter-list>  : :« 

(  [<formal-input-parameter>, . . .] 

[  :  <formal-output-parameter>, .. 

.  1  ) 

<f ormal-input-parameter>  : :■ 

[<parameter-binding>] 

<input-parameter-name> 

<f ormal-output-parameter> : 

[<parameter-binding>] 

<output-parameter-name> 

<parameter-binding>  ; :* 

BYVAL 

1 

BYREF 

1 

BYRES 

<input-parameter-name>  : :■ 

<data-name> 

(2.6) 

1 

<statement-name> 

(4.0) 

1 

<subroutine-name> 

<output-parameter-name> 

<data-name> 

(2.6) 

<subroutine-name>  : :■ 

<procedure-name> 

1 

<function-name> 

(3.2) 

Semantics: 


Parameters  permit  subroutines  to  have  locally-declared  <names>  that 
correspond  to  entities  whose  values  can  be  different  for  different 
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calls. 

<Formal-input-parameters>  and  <formal-output-parameters>  constitute 
the  formal  parameters  of  the  subroutine.  When  the  subroutine  Is 
Invoked,  the  formal  parameters  are  associated  with  a  corresponding  list 
of  actual  parameters  supplied  in  the  subroutine  call  (see  Section  4.5). 

<Formal-input-parameters>  transfer  values  into  the 

<subroutine-body>  from  the  corresponding  <actual-input-parameters>. 
<Formal-output-parameters>  transfer  values  into  the  <subroutine-body> 
and  also  transfer  values  from  the  <subroutine-body>  back  to  the 
corresponding  <actual-output-parameters> . 

If  a  formal  parameter  is  a  <data-name>  it  may  be  bound  to  the 
corresponding  actual  parameter  in  any  of  the  following  ways:  by 
reference,  by  value,  by  result,  or  by  value-result.  Reference  binding 
means  that  the  actual  parameter  and  the  formal  parameter  denote  the  same 
physical  object.  Any  change  in  the  value  of  the  formal  parameter 
entails  an  Immediate  change  in  the  value  of  the  actual  parameter  and 
vice-versa.  Value-result  binding  means  that  the  formal  parameter 
denotes  a  separate  data  object,  assigned  the  value  of  the  actual 
parameter  on  entry  to  the  subroutine,  and  used  to  assign  its  value  to 
the  actual  parameter  on  normal  exit  from  the  subroutine.  Since  it  is  a 
separate  data  object  there  is  no  Interaction  between  it  and  the  actual 
parameter  during  execution  of  the  subroutine.  Value  binding  is  similar 
except  the  actual  parameter  is  not  modified  on  exit  from  the  subroutine. 
Result  binding  leaves  the  value  of  the  formal  parameter  undefined  on 
entry  to  the  subroutine  but  is  otherwise  like  value-result  binding. 

Standard  rules  for  types  of  binding  indicate  the  effect  normally 
required: 

Reference  binding  shall  be  used  for  blocks,  tables,  and  for 
entries  of  all  except  tight  tables. 

Value  binding  shall  be  used  for  input  items  and  tight  table 
entries. 

Value-result  binding  shall  be  used  for  output  items  and  tight  table 
entries. 


Explicit  <parameter-bindlng>  specification  affects  these  rules  as 
follows: 

BYREF  -  reference  binding  is  required.  If  the  actual  parameter 
cannot  be  passed  by  reference  (such  as  a  badly  aligned 
table  item) ,  the  compiler  shall  allocate  a  temporary 
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variable,  use  value  or  value-result  binding  as 
appropriate  to  pass  the  parameter  between  its  actual 
location  and  the  temporary  variable,  and  pass  the 
temporary  variable  by  reference  to  the  subroutine. 

BYVAL  -  reference  is  prohibited.  The  parameter  shall  be  passed 
by  value  or  value-result  as  appropriate. 

BYRES  -  result  binding  is  required. 

An  implementation  may  optimize  binding  methods  provided  it 
guarantees  required  results  both  in  parameters  passed  and  in  side 
effects,  if  any. 

If  the  <fornal-input-parameter>  is  a  <statement-name> ,  a  GOTO 
statement  with  that  name  as  a  target  will  cause  the  subroutine  to  be 
exited  without  setting  any  of  the  value-result  parameters.  Execution 
will  resume  at  the  statement  named  in  the  actual  parameter  as  though  the 
GOTO  statement  had  been  executed  at  the  point  of  the  subroutine  call. 

If  the  <formal-input-parameter>  is  a  <subroutine-name>  the  <name> 
of  the  corresponding  actual  parameter  determines  which  <subroutine- 
deflnltlon>  to  associate  with  the  formal  parameter's 
<subroutlne-declaration>  on  each  call.  A  call  to  that  subroutine  via 
the  formal  parameter  <name>  will  be  treated  as  if  the  corresponding 
actual  parameter  subroutine  had  been  called  from  the  same  environment  in 
which  <subroutlne-name>  was  originally  specified  as  an 
<actual-input-parameter> . 

The  order  of  evaluation  of  actual  parameters  is  unspecified. 

In  the  absence  of  an  <interference-directive> ,  no  interference  is 
assumed  within  the  subroutine  between  actual  parameter  data  and  formal 
table  or  block  parameters,  or  between  actual  parameters  and  variables 
accessed  directly  from  within  the  subroutine. 

Constraints : 

The  same  name  must  not  appear  more  than  once  in  any 
<formal-parameter-list>. 

A  <formal-input-parameter>  cannot  be  used  in  a  context  in  which  its 
value  can  be  altered  (e.g.,  as  a  target  in  an  <assignment-statement>) . 

Names  of  data  declared  as  formal  parameters  must  not  be  used  in 
<overlay-dedarations> . 

Declarations  of  formal  parameters  must  not  contain  <allocation- 
specifiers>  or  presets. 
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<External-declaratlons>  of  formal  parameters  are  not  permitted* 

The  <subroutlne-deflnltion>  (and  <subroutine-declaratlon>,  if  one 
is  present)  must  contain  an  explicit  <declaration>  for  each  <name>  in 
the  <formal-parameter-llst>. 

For  any  subroutine  call,  the  number  of  formal  and  actual  input 
parameters  must  be  the  same,  and  the  number  of  formal  and  actual  output 
parameters  must  be  the  same. 

Declarations  of  formal  parameters  cannot  be  <constant-declarations> 
or  <type-declarations>. 

For  all  table  parameters,  the  types  of  the  formal  parameters  and 
those  of  the  corresponding  actual  parameters  must  be  equivalent  (see 
Section  7.0).  This  requirement  extends  to  the  types  and  associated 
attributes  of  all  components,  and  their  allocation  order.  For  all  item 
parameters,  the  rules  for  implicit  attribute  conversion  apply  (see 
Section  7.0).  Block  parameters  match  under  the  following  conditions: 
(1)  the  type  and  textual  order  of  the  components  match  exactly;  (2)  an 
! ORDER  directive  is  either  present  in  both  <block-body-parts>  or  absent 
in  both  <block-body-parts>;  and  (3)  <overlay-declarations>  in  both 
blocks  have  the  same  effect. 

The  actual  parameter  corresponding  to  a  formal  input  parameter 
<statement-name>  must  be  a  <statement-name>.  The  actual  parameter 
corresponding  to  a  formal  input  parameter  <subroutlne~name>  must  be  the 
name  of  a  subroutine.  Parameter  types  and  return  value  types  of  formal 
and  actual  subroutines  must  match  exactly. 

BYRES  binding  must  not  be  specified  for  input  parameters. 


3.4  INLINE  PROCEDURES  AND  FUNCTIONS 
Syntax: 

<inline-declaration>  : :*  INLINE 

<subroutine-name>, . ..  ;  (3.1) 


Semantics: 

An  <lnllne-declaratlon>  causes  the  object  code  for  the  bodies  of 
each  of  the  designated  subroutines  to  be  inserted  at  the  point  of  every 
call  of  that  subroutine  within  the  scope  containing  the 
<inline-declaration>.  This  will  be  done  instead  of  inserting  code  for 
calling  a  remote  subroutine  body. 
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The  effect  of  the  <lnline-deelaration>  extends  for  just  the  name 
scope  In  which  the  <inllne-declaratlon>  appears.  It  does  not  affect 
calls  appearing  in  enclosing  scopes. 

If  any  actual  parameters  to  inline  subroutines  are  constants, 
inline  expansion  may  cause  some  formulas  in  the  <subroutine-bodies>  to 
become  evaluable  at  compile  time.  Compile-time  evaluation  of  these 
formulas  will  be  performed  and  any  corresponding  error  messages  will  be 
generated  as  though  the  programmer  had  written  those  formulas  directly. 
Except  for  the  effects  of  compile-time  evaluation,  the  semantics  of 
inline  subroutine  expansion  are  identical  to  the  semantics  of  the 
normal,  remote  subroutine  call  mechanism. 

Inline  subroutines  may  themselves  contain  (possibly  inline) 
subroutine  calls,  but  they  may  not  contain  nested  subroutine 
definitions. 

Inline  subroutine  names  may  be  used  as  actual  parameters,  but  a 
call  to  the  matching  formal  parameter  name  will  result  in  a  closed 
rather  than  inline  invocation  (even  if  the  actual  parameter  is  an  inline 
subroutine) . 

I 

Constraints: 


Names  of  subroutines  whose  definitions  appear  in  another  module 
cannot  be  used  in  <inline-declarations>. 

Formal  parameters  cannot  be  declared  to  be  inline. 

It  is  illegal  to  have  an  inline  subroutine  invocation  of  a 
subroutine  that  is  already  being  expanded  inline. 

Formal  parameters  of  inline  subroutines  cannot  be  used  in  contexts 
where  the  syntax  requires  a  compile-time  formula. 


3.5  MACHINE-SPECIFIC  PROCEDURES  AND  FUNCTIONS 
Semantics : 

Each  compiler  implementation  may  provide  a  set  of  procedures  and 
functions  that  are  intrinsically  recognized  by  the  compiler.  These 
procedures  and  functions  shall  typically  encompass  operations  that  are 
not  directly  provided  by  the  language.  They  may  be  implemented  as 
subroutines  or  via  inline  code,  whichever  is  suitable.  The  use  of 
inline  code  is  particularly  suitable  as  a  vehicle  for  invoking  single 
machine  instructions  which  are  peculiar  to  the  target  machine. 
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In  general,  e  subroutine  will  be  provided  for  machine  instructions 
whose  execution  would  otherwise  be  unobtainable  through  the  language. 
It  is  not  Intended  that  every  target  machine  instruction  be  supported  as 
a  machine-specific  procedure  or  function.  Subroutines  will,  however,  be 
provided  for  machine-specific  instructions  whose  meaning  is  not 
expressible  in  the  language  (e.g.,  "load  status  word",  "test  condition 
code"),  as  well  aa  instructions  for  which  a  J73  subroutine  could  be 
written  but  which  are  directly  Implemented  by  target-machine 
instructions  (e.g.,  "sine",  "matrix  multiply",  or  "rotate  length-32 
bitstring",  etc.)*  Such  subroutines  will  be  defined  at  system  scope  and 
hence  their  names  will  be  redefinable  in  inner  scopes.  Such  subroutines 
will  be  invoked  in  the  same  way  as  other  subroutines  (see  Sections  4.5 
and  6.3).  The  particular  parameters  to  such  subroutines  are 
subroutine-dependent . 

Implementation  requirements  for  each  such  subroutine  include 
specification  of  the  operation  to  be  performed  and  of  the  rules  for  each 
formal  parameter,  including  both  its  JOVIAL  attributes  and  how  it  is 
used.  The  compiler  shall  generate  code  to  use  the  parameters  and 
perform  the  specified  operation. 
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4.0  STATEMENTS 
Syntax: 


<statenent> 

:  [<directive>...]  [<label>...] 

<simple-statement> 

(9.0) 

|  [<directive> .. .]  [<label>...] 

<com pound-s tatenent> 

(9.0) 

<slmple-*statement> 

<assignment-stateinent> 

(4.1) 

|  <loop-*8tatement> 

(4.2) 

|  <if-stateoent> 

(4.3) 

|  <case-statement> 

(4.4) 

|  <procedure— call—statement> 

(4.5) 

|  <return-statement> 

(4.6) 

|  <goto-statement> 

(4.7) 

|  <exit-statement> 

(4.8) 

|  <stop-statement> 

(4.9) 

|  <abort-statement> 

(4.10) 

|  <null-statement> 

<null-statement> 

»  *■  • 

•  •  » 

|  BEGIN  [<label>. . .] 

END  ' 

<label> 

<statement-name>  : 

<» tat ement-name> 

: :■  <name> 

(8.2.1) 

<compound-stateoent> 

BEGIN  <statement> . . . 
[<directive>...l 
[<label>...]  END 

(9.0) 
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Semantics : 

<Statements>  ara  che  means  by  which  computational  algorithms  are 
specified.  They  control  the  execution  of  the  <complete-program>. 

A  <compound-statement>  permits  a  sequence  of  <statements>  to  be 
used  in  contexts  requiring  a  single  <statement>. 

A  <null-statement>  results  in  no  operation. 

9 

A  <label>  is  used  to  attach  a  <statement-name>  to  a  <statement>.  A 
<label>  Chat  is  attached  to  the  END  of  a  <compound-statement>  or 
<null-statement>  is  created  as  if  a  no  operation  <statement>  followed 
the  <label>. 


4.1  ASSIGNMENT  STATEMENTS 
Syntax: 

<assignmenc-stateaent>  <variable-list>  ■ 

<formula>  ;  (5.0) 

<variable-list>  ::-  <variable> , . . .  (6.1) 

Semantical* 

An  <assignment-statement>  causes  the  value  of  the  <formula>  to  the 
right  of  the  equal  sign  to  be  assigned  to  the  <variables>  to  the  left  of 
Che  equal  sign. 

In  performing  Che  assignment,  the  <formula>  is  evaluated  first. 
Then,  the  leftmost  variable  is  evaluated  and  the  value  of  the  formula  is 
assigned  to  that  variable.  Next,  the  second-to-the-left  variable  is 
evaluated  and  the  value  of  the  formula  is  assigned  to  it.  This  sequence 
of  evaluations  continues  until  the  list  of  variables  is  exhausted.  If 
necessary  and  permitted  (see  Section  7.0),  the  value  of  the  formula  is 
implicitly  converted  to  the  type  of  the  variable  being  assigned  to.  For 
numeric  values,  the  value  is  rounded  or  truncated  according  to  the 
<round-or-truncate>  attribute  of  each  variable  being  assigned  to  (see 
Sections  2. 1.1. 2  and  2. 1.1.3). 

Constraints: 

The  type  of  the  <formula>  must  match  or  be  implicitly  convertible 
to  that  of  each  of  the  <variables>  according  to  the  rules  given  in 
Section  7.0. 
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All  <variables>  In  Che  <varlable-list>  oust  be  of  Che  same  Cype 
class. 

None  of  che  <variables>  may  be  <formal-input-parameters>. 

Note: 


Assignment  semanclcs  and  consCralnCs  apply  Co  presecs  (SecClon 
2.1.6),  assignments  Co  <control-items>  in  <loop-statements>  (Section 

4.2) ,  and  some  types  of  accual/formal  parameter  correspondence  (Section 

3.3) . 


Since  Che  implemented  precision  of  packed  fixed  point  cable  items 
may  be  less  than  the  implemented  precision  of  an  unpacked  item  having 
the  same  fixed  type,  and  since  rounding  and  truncation  are  performed 
with  respect  to  implemented  precision,  assignment  to  packed  table  items 
may  change  the  value  being  assigned  (see  Section  7.0). 


4.2  LOOP  STATEMENTS 
Syntax; 


<loop-statement> 

:  :■ 

<loop-type> 

<controlled-statement> 

<loop-type> 

: :» 

<while-clause> 

1 

<for-clause> 

<controlled-statement> 

: :» 

<statement> 

<while-clause> 

; :» 

WHILE  <boolean-f ormula>  ; 

(5.2.2) 

<for-clause> 

:  :■ 

FOR  <control-item>  : 
<control-clause>  ; 

<control-item> 

;  :■ 

<control-variable> 

1 

<control-letter> 

<control-varlable> 

:  ;■ 

<item-name> 

(2.1.1) 

<control-letter> 

:  :■ 

<letter> 

(8.1) 

<control-clause> 


<initial-value> 

[ <continuation> ] 
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<ini tial-value> 
<contlnuation> 


<byo  r- 1  hen-phr  ase> 


<by-phrase> 

<byformula> 

<then-phrase> 

<while-phrase> 

Semantics: 

A  <loop—statement>  provides  for  the  iterative  execution  of  a 
statement . 

If  the  <while-clause>  form  of  the  <loop-statement>  is  used,  the 
<controlled-statement>  i.  executed  until  the  value  of  the 
<boolean-formula>  becomes  FALSE.  The  <boolean-formula>  is  evaluated 
before  each  iteration. 

If  the  <for-clause>  form  is  used,  the  value  of  <control-item> 
determines  the  number  of  iterations.  If  the  <control-item>  is  an 
<ltem-name>,  its  type  is  as  specified  in  its  <declaration> ,  and  that 
<item-name>  may  be  used  for  purposes  other  than  loop  control  before  .  and 
after  the  loop.  After  execution  of  the  loop  concludes,  the  value  of  the 
<ltem-name>  is  the  last  value  it  received  in  the  <loop-statement>.  If 
the  <control-item>  is  a  <letter>,  the  <for-clause>  constitutes  an 
implicit  declaration  of  the  <control-item>,  and  its  value  is 
inaccessible  prior  to  the  start  of  the  <loop-statement>  and  after  the 
<loop-statement>  concludes.  Its  type  is  that  of  the  <initial-value>. 
Its  scope  is  the  <loop-statement>  itself;  hence,  another  loop  statement 
may  use  the  same  <letter>  as  a  <control-item>  (except  as  prohibited  in 
Constraints)  and  no  conflict  will  result. 

The  actions  of  the  <loop-statement>  with  a  <for-clause>  are  as 
specified  by  the  following  algorithm: 

Step  1:  The  <initlal-value>  is  evaluated  and  assigned  to  the 
<control-item>. 


::»  <formula>  (5.0) 

:  :•  <by-or-then  phrase> 

[ <whlle-phrase> ] 

|  <whlle-phrase> 

[<by-or-then-phrase> ] 

:  :•  <by-phraae> 

|  <then-phrase> 

: :«  BY  <by-formula> 

:  :•  <numeric-formula>  (5.1) 

THEN  <formula>  (5.0) 

WHILE  <boolean-formula>  (5.2.2) 
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Step  2:  The  <boolean-formula>  in  the  <while-phrase>  (if 
present)  is  evaluated.  If  it  is  FALSE,  execution  of 
the  <loop-statement>  concludes* 

Step  3:  The  <controlled-statement>  is  executed. 

Step  4:  The  formula  in  the  <by-or-then-phrase>  (if  present) 
is  evaluated.  The  value  for  the  <by-formula>  (if 
present)  is  added  to  the  <control-item>.  The  value 
of  the  <then-formula>  (if  present)  is  assigned  to 
the  <control-item>.  Execution  continues  at  Step  2. 

The  <control-item>  may  be  used  in  a  <formula>  in  the  <control- 
clause>  and  in  the  <controlled-statement>. 

Execution  of  the  <loop-statement>  concludes  if  control  is  passed  to 
another  statement  by  means  of  a  GOTO,  RETURN,  EXIT,  STOP,  or  ABORT 
statement. 

Constraints : 

If  the  <control-item>  is  a  <letter>,  it  must  not  be  used  in  the 
<controlled-statement>  or  <control-dause>  in  any  context  in  which  its 
value  can  be  altered  (e.g.,  as  an  <actual-output-parameter>  or  as  a 
target  in  an  <assignment-statement>) .  If  the  <control-item>  is  an 
<ltem-name>,  assignments  to  it  in  the  <controlled-statement>  are  not 
prohibited,  but  will  result  in  a  warning  message. 

A  <label>  in  a  <controlled-statement>  cannot  be  used  as  the 
<statement-name>  in  a  <goto-statement>  or  <abort-phrase>  that  is  outside 
the  <controlled-statement>  or  as  an  <actual-input-parameter>  in  a 
subroutine  invocation  chat  is  outside  the  <c oner oil ed-statement>. 

The  <initial-value>,  <by-formula>  and  <then-formula>  must  match  or 
be  implicitly  convertible  to  the  type  of  the  <control-item>  (see  Section 
7.0).  Further,  the  sum  of  the  <by-formula>  and  the  <control-item>  must 
match  or  be  Implicitly  convertible  to  Che  type  of  the  <control-item>. 
The  <initial-value>  cannot  be  of  type  table. 

The  <by-formula>  (if  present)  must  have  type  and  value  such  that  it 
may  be  legally  added  to  the  <control-ltem>  according  to  the  rules  of 
Sections  5.1.1,  5.1.2,  and  5.1.3. 

If  the  <control-item>  is  a  <control-letter>,  the  <initial-value> 
must  not  be  a  <status-constant>  that  belongs  to  more  than  one  type 
(unless  the  <status-constant>  is  disambiguated  by  an  explicit  conversion 
—  see  Section  7). 

The  <control-letter>  in  a  <loop-statement>  may  not  be  the  same  as 
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Ch*  <control-letter>  of  any  enclosing  <loop— statement>. 

A  <bit-formula>  cannot  be  implicitly  converted  to  the 
<boolean-formula>  in  a  <while-phrase>. 


4.3  IF  STATEMENTS 


Syntax: 


<if-statement> 

: :■  IF  <boolean-foraula>  ; 
<conditional-statement> 
(<else-clause> ] 

(5.2.2) 

<conditional-statement> 

<statement> 

(4.0) 

<else-clause> 

[<directlve>...] 

ELSE  <statement> 

(9.0) 

(4.0) 

Semantics: 

An  <if-statement> 
depending  on  the  value 

provides  for  conditional  execution  of 
of  its  <boolean-formula>. 

a  statement 

If  the  value 
<condl t ional-s tat  ement> 

of 

is 

the  <boolean-formula>  is  TRUE,  the 

executed  and  the  <statement>  in  the  ELSE 

clause  (if  any)  is  not  executed. 

If  the  value  of  the  <boolean-formula>  is  FALSE,  the  <statement>  in 
the  <else-clause>  (if  present)  is  executed  rather  than  the 
<conditional-statement>.  In  the  event  of  nested  <lf-statements> ,  an 
ELSE  associates  with  the  innermost  unmatched  IF. 

If  the  <boolean-formula>  has  a  value  that  is  known  at  compile  time, 
conditional  compilation  (see  Section  1.2.4)  will  occur. 

Constraints: 


<Labels>  throughout  a  scope  must  be  unique,  even  if  portions  of  the 
text  within  the  scope  are  unselected  as  a  result  of  conditional 
compilation. 

<Directives>  preceding  ELSE  must  be  text  directives  (Section  9.2) 
or  listing  directives  (Section  9.7). 

A  <bit-formula>  cannot  be  implicitly  converted  to  the 
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<boolean-formula>  in  an  <if-scacemenc>. 

Note; 

<Labela>  In  Che  <condlcional-scacemenC>  and  in  che  <else-clause> 
are  In  che  sane  scope  as  che  <lf-sCaCemenc>  lcself. 


4.4  CASE  STATEMENTS 


Sync ax: 


<case~scacemenc> 

•  •  mi 

CASE 

<case-selecCor-foraula>  ; 
[<direccive>. . .] 

BEGIN  <case-body> 

[<label>. . .}  END 

(9.0) 

(4.0) 

<case-seleccor-fonnula> 

•  •  jg 

<inceger-formula> 

(5.1.1) 

1 

<biC-formula> 

(5.2) 

1 

<characcer-formula> 

(5.3) 

1 

<scacus-forauIa> 

(5.4) 

<case-body> 

: :» 

<case-alcernative> . . . 

<case-alternacive> 

:  :» 

[  <direccive>. ..  ] 
<case-index-group> 

<scacemenc> 

[FALLTHRU] 

(9.0) 

(4.0) 

1 

<defaulC-opCion> 

<def aulc-opcion> 

•  • 

[<direccive>...] 

(  DEFAULT  )  : 

<statement> 

( FALLTHRU J 

(9.0) 

(4.0) 

<case— index-group> 

(  <case-index> , . . .  )  : 

<case—index> 

•  • 

<  c  omp i le- c ime- i nc  ege  r-f o  rmula> 

(5.1.1) 

1 

<conpile-cime-bic-formula> 

(5.1.2) 

1 

<compile-cime-characcer- 

formula> 

(5.1.3) 
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I  <compile— t  ime-s  tatus-f  orraula>  (5.4) 

I  <lower-bound>  :  (2. 1.2.1) 

<upper-bound>  (2. 1.2.1) 


Semantics : 


Whereas  an  <if-statement>  provides  for  the  optional  execution  of 
either  of  two  statements,  a  <case-statement>  provides  for  a  choice  of 
executing  one  or  more  of  a  number  of  statements.  (The  possible  choices 
are  represented  by  the  various  <case-alternatlves» . 

The  particular  <case-alternative>  is  selected  according  to  the 
value  of  <case-selector-formula>.  Several  values  of  the  <ca se-s elect or- 
formula>  may  select  the  seise  < case-alt ernatlve>. 

With  the  exception  of  the  <default-optlon>,  each  <case-alternatlve> 
is  headed  by  a  <case-index-group>  that  designates  the  possible  values  of 
the  <case-selector-fdrmula>  that  after  being  Implicitly  converted  (if 
necessary)  to  the  type  of  the  <case-selector-formula>,  cause  that 
particular  <caae-alternative>  to  be  selected  for  execution.  Each 
<case-index>  can  designate  either  a  single  value  or,  for  Integer  and 
status  selector  types,  a  closed  range  of  values  bounded  by  <lover-bound> 
and  <upper-bound>. 

If  the  value  of  the  <case-selector-formula>  does  not  correspond  to 
a  <case-index>  value,  the  <statement>  in  the  <default-optlon>  is 
executed. 

If  FALLTHRU  is  not  present  after  a  selected  <statement>,  execution 
of  the  <case-statement>  concludes  after  that  <statement>  is  executed. 
If  FALLTHRU  is  present  after  the  selected  <statement>,  the  <statement> 
in  the  textualiy-succeedlng  <case-alternative>  is  then  executed. 
Control  continues  to  "fall  through"  to  subsequent  <case-altematlves>, 
until  a  case-alternative  with  no  FALLTHRU  is  executed  or  until  the  END 
of  the  <caae-statement>  has  been  reached. 

If  the  value  of  the  <case-selector-formula>  is  known  at  compile 
time,  conditional  compilation  (see  Section  1.2.4)  will  occur  for  all 
unselected  alternatives  that  cannot  be  reached  via  FALLTHRU  semantics. 

Constraints : 

No  two  <case-alternatlves>  within  the  same  <case-statement>  can  be 
associated  with  identical  <case-index>  values. 

If  a  <default-optlon>  is  not  present,  the  value  of  the 
<case-selector-formula>  must  be  represented  by  a  <case-index>. 
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The  type*  of  eech  formula  In  a  <case-index>  must  match  or  be 
implicitly  convertible  to  that  of  the  <case-selector-formula>  according 
to  the  rules  given  in  Section  7.0. 

If  the  <case-selector-formula>  is  a  <status-formula>,  a 
<case-index>  specifying  lower  and  upper  bounds  is  legal  only  if  the 
status-type  has  the  default  representation  (see  Section  2. 1.1. 6). 

The  <upper-bound>  in  a  <case-index>  must  be  greater  than  or  equal 
to  the  <lower-bound> . 

<Directives>  preceding  DEFAULT  or  <case-index-groups>  must  be  text 
directives  (Section  9.27)  or  listing  directives  (Section  9.7). 

Within  a  <case-statement> ,  at  most  one  <default-optlon>  may  be  used 
as  a  <case-alternative>. 

Note; 

<Labels>  in  the  <default-option>  and  in  the  <case-alternatives>  are 
in  the  same  scope  as  the  <case-statement>  itself.  Consequently,  control 
can  be  transferred  into  or  between  case  statements. 


4.5  PROCEDURE  CALL  STATEMENTS 


Syntax; 

<procedure-call- 

statement>  ;  :■  <user-def ined-procedure-call> 

J  <machine-specif ic-procedure-call> 


<user-def ined-procedure- 

call>  :  ;■ 

<  pr ocedure-name> 

[ <actual-parameter-lis t> ) 
[<abort-phrase>]  ; 

(3.1) 

<actual-paramecer-list>  ;;■ 

(  [ <actual-input-parameter> ,...] 

[  :  <actual-output-parameter> , . . 

.  1 

<actual-input-parameter>  ; :« 

<formula> 

(5.0) 

1 

<statement-name> 

(4.0) 

I 

<function-name> 

(3.2) 

\ 

<procedure-name> 

(3.1) 
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I  <block-name>  (2.1.4) 

I  <block-dereference>  (6.1) 

I  <nested-block> 

<nested-block>  <block-name>  (2.1.4) 

[<block~dereference>]  (6.1) 

<ac  tual-out put- 

parameter>  <variable>  (6.1) 

I  <biock-name>  (2.1.4) 

I  <block-dereference>  (6.1) 

I  <nested-block> 

<abort-phrase>  :  :■  ABORT  <statement-name>  (4.0) 

<machlne-speclf lc- 

procedure-call>  <procedure-name>  (3.1) 


[<actual-parameter-list>]  ; 


Semantics: 


A  <procedure-call-statement>  causes  Invocation  of  a  procedure  and 
the  association  of  formal  parameters  with  actual  parameters  according  to 
the  rules  given  In  Section  3.3. 

A  <user-defined-procedure-call>  causes  invocation  of  a  procedure 
defined  in  a  <procedure-def inition>.  The  <abort-phrase>  is  for  use  In 
connection  with  <abort-statements>.  Its  semantics  are  explained  in 
Section  4.10. 

A  <machine-specific-procedure-call>  causes  invocation  of  a  machine" 
specific  procedure  (see  Section  3.5). 

A  <nested-block>  is  a  block  contained  in  another  block.  If  the 
<block-name>  was  declared  in  a  <block-type-dedaration>,  the  <block- 
dereference>  references  the  particular  block  from  which  the  nested  block 
is  to  be  obtained. 

Constraints: 

Actual  parameters  in  the  <pr.ocedure-call-statement>  must  match  the 
formal  parameters  of  the  called  procedure  in  number,  kind,  and  parameter 
list  position,  according  to  the  rules  given  in  Section  3.3. 
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The  <statement-name>  in  an  <abort-phrase>  or 
<actual-input-parameter>  must  be  known  in  the  scope  in  which  the 
<procedure-call-atatement>  appears,  but  it  must  not  name  a  statement 
that  is  in  another  module  or  in  an  enclosing  subroutine  or  that  was  in 
unselected  text  in  conditional  compilation.  It  cannot  be  the  name  of  a 
statement  that  is  in  a  <controlled-statement>  unless  the 
<procedure-call-statement>  '  itself  is  within  that  same 
<controlled-statement> . 


4.6  RETURN  STATEMENTS 
Syntax; 

<return-statement>  : :■  RETURN  ; 

Semantics : 


The  effect  of  a  <return-statement>  is  to  terminate  the  execution  of 
a  subroutine,  set  any  parameters  that  have  value-result  semantics,  and 
return  control  to  the  point  following  the  invocation  of  the  subroutine. 
If  the  <return-statement>  is  in  a  <function-body> ,  the  current  value  of 
the  <function-name>  becomes  the  value  of  the  function  call. 

If  the  subroutine  containing  the  <return-statement>  is  nested 
within  any  enclosing  subroutines,  only  the  Innermost  subroutine  is 
terminated. 

Constraint ; 

The  <return-statement>  can  appear  only  within  the  body  of  a 
subroutine. 


4.7  GOTO  STATEMENTS 
Syntax: 

<goto-statement>  ; GOTO  <statement-name>  ;  (4.0) 

Semantics: 

A  <goto-statement>  causes  control  to  be  transferred  to  the 
statement  named  by  the  specified  <statement-name>. 

When  the  <statement-name>  is  a  formal  statement-name  parameter,  the 
effect  of  a  <goto-statement>  is  equivalent  to  returning  from  the  current 
subroutine  invocation  without  setting  value-result  parameters  and  then 
executing  a  <goto-statement>  at  the  point  of  the  subroutine's 
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Invocation. 

Constraints i 

The  <statement-name>  aust  be  known  in  the  scope  in  which  the 
<goto-statement>  appears.  Further,  the  <statement-name>  oust  not  be  the 
<label>  of  a  statement  that  is  in  an  enclosing  subroutine  or  in  another 
module.  It  cannot  be  the  <label>  of  a  statement  in  a 
<controlled-statement>  unless  the  <goto-stateoent>  is  Itself  within  that 
same  <controlled-statement>. 


4.8  EXIT  STATEMENTS 
Syntax: 

<exlt-statement>  EXIT  ; 

Semantics: 

An  <exlt-statement>  causes  execution  of  the  immediately  enclosing 
<loop-statement>  to  terminate.  Its  effect  is  the  same  as  a  GOTO 
statement  that  transfers  control  out  of  the  <controlled-statement>  to 
the  point  following  the  end  of  the  <loop-statement> . 

Constraint: 


The  <exit-statement>  can  appear  only  in  a  <controlled-statement>. 
4.9  STOP  STATEMENTS 
Syntax: 

<stop-statement>  STOP  [<integer-fonnula>]  ;  (5.1.1) 

Semantics : 

A  <stop-s tat erne nt>  causes  execution  of  the  <complete-program>  to 
terminate.  If  a  <stop-statement>  is  executed  within  a 
<subroutine-body> ,  the  value-result  <actual-output-parameters>  of  any 
subroutine  whose  call  is  still  active  will  not  be  set. 

The  value  of  the  optional  <integer-formula>  in  a  <stop-statement> 
is  made  available  to  the  environment  in  which  the  J73  program  is 
executing,  where  its  semantics  are  implementation-dependent.  Absence  of 
an  <lnteger-formula>  implies  the  value  is  not  determined. 
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Constraint: 

The  range  of  legal  values  of  the  <lnteger-formula>  Is  MINSTOP 
through  MAXSTOP. 


4.10  ABORT  STATEMENTS 
Syntax: 

<abort-statement>  : :■  ABORT  ; 

Semantics : 


When  an  <abort-statement>  Is  executed,  control  passes  to  the 
statement  named  In  the  <abort-phrase>  of  the  most  recently  executed, 
currently  active  <procedure-call-statement>  that  has  an  <abort-phrase>. 
All  Intervening  subroutine  Invocations  are  terminated,  and  value-result 
parameters  of  such  subroutines  are  not  set.  If  there  Is  no 
currently-actlve  <procedure-call-statement>  that  has  an  <abort-phrase>, 
the  effect  of  the  <abort-statement>  Is  the  same  as  STOP. 
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5.0  FORMULAS 
Syntax: 
<fornula> 


<compile-t ime-f ormula> 


<numeric-f ormula>  (5.1) 
<bit-formula>  (5.2) 
<character-formula>  (5.3) 
<status-formula>  (5.4) 
<pointer-foraula>  (5.5) 
<table~formula>  (5.6) 
<compile-time-numeric-formula>  (5.1) 
<compile-time-bit-formula>  (5.2) 
<compile-time-character-f ormula>  (5.3) 
<compile-time-status-formula>  (5.4) 
<compile-time-pointer-formula>  (5.5) 


Semantics: 


<Formulas>  represent  values.  Each  <formula>  has  associated  with  It 
a  type  class  and  appropriate  attributes. 

A  <compile-time-formula>  is  a  <formula>  whose  value  is  computed  and 
used  at  compile  time. 

All  compile-time  computations  are  performed  using  the  range  and 
precision  parameters  of  the  target  machine. 

The  following  constructions  yield  values  at  compile  time. 

1.  Data  declared  in  <constant-item-declarations>,  except  for 
constant  items  whose  type  class  is  pointer. 

2.  The  functions  LBOUND,  FIRST,  and  LAST,  regardless  of 
their  arguments;  the  function  UBOUND,  provided  its 
argument  is  not  a  table  with  *  dimensions;  the  functions 
NEXT,  BIT,  BYTE,  SHIFTL,  SHIFTR,  ABS,  and  SGN,  provided 
their  arguments  are  known  at  compile  time;  the  function 
NWDSEN,  provided  its  argument  does  not  contain  a 
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reference  Co  a  name  whose  declaration  Is  not  completed 
prior  to  the  point  at  which  the  function  appears;  the 
functions  BITS1ZE,  BYTESIZE,  and  WORDSIZE,  provided  (1) 
their  arguments  are  known  at  compile  time,  (2)  their 
arguments  do  not  contain  references  to  names  whose 
declarations  are  not  completed  prior  to  the  points  at 
which  the  functions  appear,  and  (3)  their  arguments  are 
not  blocks  and  are  not  tables  with  *  dimensions. 

3.  All  operator-operand  combinations  other  than 
dereferencing,  indexing,  and  assignment,  provided  the 
operands  have  values  chat  are  known  at  compile  time. 

4.  All  type  conversions  except  REP,  provided  the  value  of 
the  <foraula>  being  converted  is  known  at  compile  time. 

5.  All  machine  parameters. 

6.  All  <status-constants>. 

7.  All  <llterals>. 

The  following  values  are  not  known  at  compile  time: 

1 .  Constant  items  whose  type  class  is  pointer. 

2.  Constant  tables  and  their  components* 

3.  All  data  declared  without  the  word  CONSTANT. 

4.  The  LOC  function,  regardless  of  its  argument;  the 
function  UBOUND,  if  its  argument  is  a  table  with  * 
dimensions;  the  functions  NEXT,  BIT,  BYTE,  SHIFTL, 
SHIFTR,  ABS,  and  SGN,  if  they  have  one  or  more  arguments 
whose  values  are  not  known  at  compile  time;  the  function 
NWDSEN,  if  its  argument  is  a  name  whose  declaration  is 
not  completed  prior  to  the  point  at  which  the  function 
appears;  the  functions  BITSIZE,  BYTESIZE,  and  WORDSIZE, 
if  (1)  their  arguments  have  values  that  are  not  known  at 
compile  time,  (2)  their  arguments  contain  references  to 
names  whose  declarations  are  not  completed  prior  to  the 
points  at  which  the  functions  appear,  or  (3)  their 
arguments  are  blocks  or  tables  with  *  dimensions. 

5 .  All  operator-operand  combinations  that  have  one  or  more 
evaluated  operands  whose  values  are  not  known  at  compile 
time. 
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6.  The  REP  conversion. 

7.  Any  value  arrived  ae  via  a  <statement>. 

8.  Dereferenced  or  subscripted  values. 

Any  value  known  at  compile  eiae  aay  also  be  used  as  a  run-time 
value. 

5.1  NUMERIC  FORMULAS 
Syntax: 

<numeric-foraula>  <lnteger-formula>  (5.1.1) 

I  <floating-fonnula>  (5.1.2) 

1  <flxed-formula>  (5.1.3) 

<compile-time-numeric-formula>: :•  <compile-time-integer-formula>  (5.1.1) 

I  <compile-time-floating-fonBula>(5.1 .2) 

I  <cpmpile-time-fixed-formula>  (5.1.3) 

Semantics: 

A  <numerlc-formula>  represents  a  numeric  value. 

A  <cooplle-tlme-numerlc-formula>  represents  a  numeric  value  that  is 
known  at  compile  time  (see  Section  5.0). 

5.1.1  INTEGER  FORMULAS 
Syntax: 

<integer-formula>  [<sign>]  <integer-term> 

|  <integer-formula> 

<plua-or-ainus> 

<integer-term> 

<integer-term>  : <integer-factor> 

I  <integer-tecm> 

<multiply-divide-or-mod> 
<integer-factor> 


(8.3.1) 

(8.2.3) 

(8.2.3) 
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<integer-factor>  : <integer-prlmary> 

|  <integer-factor>  ** 
<lnteger-primary> 

<integer-prlmary>  <lnteger-llteral>  (8.3.1) 

I  <integer-machine- 

parameter>  (1.4) 

I  <integer-varlable> 

|  <named-integer-constant> 

|  <integer-function-call> 

|  (  <integer-formu!a>  ) 


|  <integer-converslon>  (7.0) 

.  (  <formula>  )  (5.0) 

<integer-varlable>  <varlable>  (6.1) 

<named-integer-constant>  <named-constant>  (6.2) 

<integer-function-call>  JCfunction-call>  (6.3) 

<cotnpile-tIme-integer-f  ormula>  s <integer-f  onnula> 

Semantics: 


An  <integer-formula>  represents  a  value  whose  type  class  Is 
Integer,  i.e.,  S  or  U. 

The  Integer  operators  are  +,  MOD,  and  **,  which  denote 
addition,  subtraction,  multiplication,  division,  modulus,  and 
exponentiation,  respectively. 

The  type  of  a  formula  composed  of  an  integer  operator  and  two 
operands  is  S  NN-1 ,  where  NN  is  the  actual  number  of  bits  that  would  be 
supplied  by  the  implementation  for  a  signed  an  integer 
<item-declaration>  whose  size  attribute  is  the  larger  of  the  size 
attributes  of  the  two  operands.  The  type  of  an  <integer~formula> 
consisting  of  a  <aign>  and  an  <lnteger-term>  is  S  NN-1 ,  where  NN  is  the 
actual  number  of  bits  that  would  be  supplied  for  a  signed  integer 
<item-declaration>  whose  size  attribute  is  that  of  the  <integer-term>. 

The  quotient  of  two  integers  is  first  computed  exactly  and  then 
truncated  to  an  integer  result.  Truncation  will  be  toward  zero. 
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The  modulus  of  two  Integers,  AA  MOD  BB,  is  equivalent  to  AA  - 
(AA/BB)*BB. 

the  value  produced  by  integer  exponentiation  to  a  poaltive  power  la 
the  same  as  that  produced  by  repeated  multiplication. 

The  value  produced  by  Integer  exponentiation  to  a  negative  power  la 
1  /  (base  **  aba  (power)  )  and  in  most  cases  is  aero. 


Constraints: 

The  value  of  an  <integer-formula>  with  size  attribute  SS  must  lie 
in  the  range  MININT(SS)  through  MAXINT(SS). 

An  <integer-variable> ,  <named-integer-constant>,  or  <integer- 
function-call>  must  be  an  integer  (S  or  0)  type. 

A  <compile-time-integer-formula>  must  be  an  <integer-foraula>  whose 
value  is  known  at  compile-time  (see  Section  5.0). 

The  right  operand  of  /  and  MOD  must  be  non-zero. 


Note: 


R  and  T  used  in  an  explicit  conversion  (see  Section  7.0)  do  not 
affect  the  value  of  integer  division. 


5.1.2  FLOATING  FORMULAS 


Syntax: 

<floating-foroula> 


<floating-term> 


<floating-factor> 


::-  [<sign>]  <floating-tera>  (8.3.1) 

|  <floating-formula> 

<plus-or-minus>  (8.2.3) 

<floating-term> 

:  :■  <f loating-f actor> 

|  <floating-term> 

<multiply-or-divide>  (8.2.3) 

<f loating-f actor> 

: :*  <f loating-primary> 

|  <floating-factor> 

**  <floatlng-primary> 
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|  <floating-factor> 

**  <integer-primary>  (5.1.1) 

<floatlng**prlmary>  <floating-literal>  (8.3.1) 

I  <f loating-machlne-parame ter>( 1.4) 

|  <floating-varlable> 

I  <named-floating-constant> 

I  <floating-funetion-call> 

I  (  <floating-formula>  ) 


I  <floating-conversion>  (7.0) 

(  <formula>  )  (5.0) 

<f loatlng-variable>  <varlable>  (6.1) 

<naaed-floating-constant>  <named-constant>  (6.2) 

<f loating— function-call>  : :■  <function-call>  (6.3) 

<compile-tinie-flaating-f  or»ula> :  :•  <floating-fonnula> 

Semantics : 


A  <floating-formula>  represents  a  value  whose  type  class  is  float. 

The  floating  operators  are  +,  *,  /,  and  **,  which  denote 
addition,  subtraction,  multiplication,  division,  and  exponentiation 
respectively.  In  exponentiation  with  a  <floating-factor> ,  a  floating 
value  is  produced  in  all  cases. 

The  precision  attribute  of  a  <floating-formula>  is  that  of  the 
formula's  most  precise  floating  operand.  The  operand  of  a 
<floating-conversion>  is  first  computed  according  to  the  default  rules, 
and  then  converted  to  the  specified  floating  type  (see  Section  7.0). 

For  floating  exponentiations  whose  right  operand  is  an 
<integer-primary>,  the  result  is  -(  ABS  (  left  operand  )  **  right 
operand  )  if  left  operand  is  negative  and  right  operand  is  odd;  (  ABS  ( 
left  operand)  **  right  operand  )  in  all  other  cases. 


Constraints: 
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The  value  of  a  <floating-formula>  with  precision  PP  must  lia  In  the 
range  FLOATUNDERFLOW  (II)  through  MAXFLOAT  (II)  or  the  range  MINFLOAT 
(II)  through  -FLOATUNDERFLOW  (II)  or  be  zero,  where  II  - 
IMPLFLQATPRECISION(PP) . 

A  <floatlng-varlable>,  <named-f loatlng-conatant> ,  or  <floating— 
function-call>  must  be  a  floating  type. 

A  <coaplle-tlme-floating-foraula>  must  be  a  <floatlng-formula> 
whose  value  is  known  at  compile  time  (see  Section  5.0). 

For  exponentiations  where  the  right  operand  is  a 
<floating-prlmary> ,  the  left  operand  must  not  be  negative. 

Exponentiation  of  an  integer  base  to  a  floating  power  cannot  be 
performed.  Either  the  base  must  be  converted  to  floating  or  the  power 
must  be  converted  to  integer. 

The  divisor  must  be  non-zero. 


Note: 


The  round  or  truncate  attribute  associated  with  variables  or 
constant  names  does  not  affect  the  computation  of  floating  formula 
results.  Floating  formulas  are  evaluated  in  an  implementation-dependent 
manner  with  respect  to  how  exact  results  are  approximated  to  the 
Implemented  precision. 


5.1.3  FIXED  FORMULAS 


Syntax: 

<flxed-formula> 


<fixed-term> 


:  (<sign>]  <fixed-term>  (8.3.1) 

)  <f ixed-formula> 

<plus-or-minus>  (8.2.3) 

<f ixed-term> 

<f ixed-factor> 

I  <fixed-term>  * 

<fixed-factor> 

|  <integer-term>  *  (5.1.1) 

<fixed-factor> 

I  <fixed-term> 

<multiply-or-divlde>  (8.2.3) 
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<integer-factor>  (5.1.1) 

<fixed-factor>  <flxed-llteral>  (8.3.1) 

|  <fixed-machine-parameter>  (1.4) 

i  <fixed-variable> 

|  <named-f lxed-constanc> 

I  <fixed-function-eall> 

|  (  <f ixed-formula>  ) 


|  <fixed-conversion>  (7.0) 

(  <fixed-term>  / 

<fixed-factor>  ) 

|  <fixed-conversion>  (7.0) 

(  <integer-term>  / 
<fixed-factor>  ) 

|  <fixed-conversion>  (7.0) 

(  <formu!a>  )  (5.0) 

<fixed-variable>  <varlable>  (6.1) 

<named-fixed-constant>  < named-cons tant>  (6.2) 

<fixed-function-call>  <function-call>  (6.3) 

<compile-time-f lxed-formula>  : <f ixed-formu!a> 

Semantics: 

A  <f ixed-formula>  represents  a  fixed  point  value. 


The  fixed  point  operators  are  +,  *,  and  /,  which  denote 
addition,  subtraction,  multiplication,  and  division,  respectively.  The 
rules  specifying  the  result  type  of  these  operators  guarantee  that,  in 
general,  exact  results  are  produced.  The  specific  rules  are  given  below 
for  each  operator.  In  these  rules,  Sn,  Fn,  and  Pn  refer  to  the  scale, 
fraction  part,  and  precision  of  an  operand  or  result  and  n  is  1,  2,  or  R 
to  indicate  the  first  operand,  second  operand,  or  result,  respectively. 

For  addition  and  subtraction,  the  default  type  of  the  result  is: 
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PR  -  Max  (P1,P2) 

For  multiplication,  chore  ere  two  cases: 

1.  When  one  operand  Is  an  integer,  the  result  scale  and 
precision  is  that  produced  by  successive  addition,  l.e., 

SR  -  Sa 
PR  ■  Pa 
PR  »  Fa 

where  Sa,  Fa,  and  Pa  represent  the  scale,  fraction,  and 
precision  values  of  the  fixed  point  operand. 

2.  When  both  operands  are  fixed  point  types,  the  type  of  the 
result  is: 

SR  -  Si  +  S2 
PR  -  PI  +  P2 
FR  -  FI  +  F2 

If  PR  is  larger  than  MAXFIXEDPRECISION  or  if  SR  does  not  lie  in  the 
range  -  127  through  +  127,  then  the  product  must  be  explicitly  converted 
to  a  valid  fixed  point  scale  and  precision  (see  Section  7.0). 

For  division,  there  are  also  two  cases: 

1.  When  dividing  a  fixed  point  value  by  an  Integer,  the 
scale  and  precision  of  the  result  are  the  scale  and 
precision  of  the  numerator.  Truncation  will  be  toward 
zero. 

2.  When  both  operands  are  fixed  point  values  or  when  an 
integer  is  divided  by  a  fixed  point  value,  the  result  is 
exact  and  must  be  explicitly  converted  to  a  programmer 
specified  scale  and  precision  (see  Section  7.0). 

The  default  result  type  of  a  <fixed-formula>  containing  a  <sign>  as 
a  prefix  operator  is  the  type  of  the  operand. 

The  result  type  of  a  <fixed-factor>  that  is  a  <f ixed-variable>, 
< named- f ixed-constant> ,  or  <fixed-function-call>  is  the  type  specified 
in  their  respective  variable,  constant,  or  function  declarations. 

The  type  of  a  <flxed-llteral>  is  contextually  determined  (see 
Section  8.3.1). 

The  result  type  of  a  <fixed-formula>  enclosed  in  parentheses  is  the 
type  of  the  enclosed  <flxed-formula>. 
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The  result  type  of  a  <fixed-factor>  containing  a  < f ixed-c onve  r s ion> 
la  the  type  specified  by  the  <f ixed-c onversion>.  If  the  operand  of  the 
<f ixed-conversion>  is  a  <fix^d-tera>  or  <fixed-formula>,  the  infix  or 
unary  operator  is  evaluated  exactly,  and  the  mathematically-defined 
result  is  converted  to  the  specified  fixed  type. 

Constraints: 


Except  for  the  operand  of  a  <f ixed-c onve rslon>,  the  value  of  a 
<fixed-formula>  whose  scale  is  SS  and  whose  fraction  attribute  is  FF 
must  lie  in  the  range  MINFIXED(SS.PP-SS)  through  MAXFIXED(SS.PP-SS) , 
where  PP  -  IMPLFIXEDPRECISION  (SS.FF). 

A  <fixed-varlable>,  <named-f ixed-constant>,  and  <f ixed-function- 
call>  must  have  been  declared  as  fixed  types. 

Operands  of  fixed  point  addition  or  subtraction  must  have  identical 
scales . 

A  <compile-time-f ixed-formula>  must  be  a  <f ixed— formula>  whose 
value  is  known  at  compile  time  (see  Section  5.0). 

The  divisor  must  be  non-zero. 


Note: 

MOD  and  **  are  not  defined  for  fixed  point  operands. 


5.2  BIT  FORMULAS 
Syntax: 

<bit-formula> 


<logical-operand> 


<bit-primary> 


<logical-operand> 

[<logical-continuation>] 

I  NOT  <loglcal-operand> 

<bit-primary> 

|  <relational-expresslon>  (5.2.1) 

<bit-literal>  (8.3.2) 

|  <boolean-literal>  (8.3.3) 


|  <bit-variable> 


MIL-STD-1589B  (USAF) 
06  June  1980 


1 

<  named-bi t-c  ons  t  ant> 

1 

<bi t- f unc t ion-call> 

1 

(  <bit-formula>  ) 

t 

<bit-conve rs ion> 

(  <formula>  ) 

(7.0) 

(5.0) 

<logical-c  ont inua ti on> 

:  :■ 

<and-contlnuatlon> ... 

1 

<or-contlnuation> . . . 

1 

<xor-contlnuatlon>. . . 

1 

<eqv-continuation> ... 

<and-contlnuation> 

AND  <loglcal-operand> 

<or-continuation> 

•  •  M 

•  • 

OR  <loglcal  operand> 

<xor-continuation> 

•  ■ 

XOR  <logical— operand> 

<eqv-contlnuatlon> 

*  •« 

•  • 

EQV  <logical-operand> 

<bit-variabla> 

•  a 

•  • 

<variable> 

(6.1) 

<  named-b it-c ons  t  ant > 

:  :■ 

<named-cons  tant> 

(6.2) 

<bit-function-call> 

:  :■ 

<  f unct ion-call> 

(6.3) 

<compile-time-bit-formula> 

• 

<bit-formula> 

Semantica: 


A  <bit-formula>  represents  a  value  whose  type  class  Is  bit.  Its 
size  la  the  number  of  bits  comprising  its  value. 

If  the  <blt-formula>  is  composed  of  <loglcal-operands>  and  one  or 
more  of  the  logical  operators  AND,  OR,  XOR,  and  EQV,  the  size  of  the 
result  is  the  size  of  the  longest  operand.  Shorter  operands  are  padded 
on  the  left  with  zeros  as  necessary.  Note  that  the  syntax  requires 
explicit  parentheses  for  all  <bit-formulas>  containing  two  or  more  of 
these  operators,  unless  the  operators  are  identical. 

NOT  produces  a  value  that  is  the  logical  complement  of  its  operand. 
AND,  OR  (inclusive  or),  XOR  (exclusive  or),  and  EQV  (equivalence) 
perform  their  usual  logical  function  on  their  two  operands  on  a 
bit-by-bit  basis.  If  both  operands  have  a  size  of  one  bit  and  the  value 
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of  the  left  operand  Is  such  chat  che  result  of  the  operator  can  be 
determined,  evaluation  is  "short-circuited",  i.e.,  the  right  operand 
will  not  be  evaluated  and  need  only  satisfy  semantic  constraints  that 
can  always,  even  in  the  most  general  case,  be  verified  without 
evaluating  the  operand  (e.g.,  the  operand  need  not  satisfy  the  division 
by  zero  constraint  if  it  is  not  evaluated). 

Constraints: 

A  <bi t-variable>  must  be  a  <varlable>  whose  type  class  is  bit. 

A  <named-bit-constant>  must  be  a  <named-constant>  whose  type  class 
is  bit. 

A  <bit-function-call>  must  be  a  <function-call>  whose  result  value 
is  bit. 

A  <compile-time-bit-formula>  must  be  a  <bit-formula>  whose  value  is 
known  at  compile  time  (see  Section  5.0). 


5.2.1  RELATIONAL  EXPRESSIONS 


Syntax: 

<relatlonal-expression> 


: :»  <integer-fonnula> 

<relational-operator> 

< int ege r- f o rmula> 

(5.1.1) 

(8.2.3) 

(5.1.1) 

|  <floating-formula> 
<relational-operator> 
<floating-formula> 

(5.1.2) 

(8.2.3) 
(5.1.2) 

|  <fixed-formula> 

<relational-operator> 

<fixed-formula> 

(5.1.3) 

(8.2.3) 

(5.1.3) 

|  <character-formula> 
<relational-operator> 
<character-formula> 

(5.3) 

(8.2.3) 

(5.3) 

I  <status-formula> 

<  r elat ional-opera tor> 
<status-formula> 

(5.4) 

(8.2.3) 

(5.4) 

I  <bit-primary> 

<equal-or-not-equal-operator> 

<bit-primary> 

(5.2) 

(8.2.3) 

(5.2) 
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I  <pointer-formula>  (5.5) 

<relatlonal-operaCor>  (8.2.3) 

< point er-f orm ul a>  (5.5) 

Sanantica: 

A  <relatlonal-expresslon>  represents  a  value  obtained  by  comparing 
two  formulas  using  a  <relational-operator>.  Its  type  class  is  B  and  its 
size  is  one  bit. 

The  relational  operators,  ■  (equal),  O  (not  equal),  <  (less  than), 
>  (greater  than),  <•  (less  than  or  equal),  and  >“  (greater  than  or 
equal),  carry  their  usual  meanings. 

Character  comparisons  will  be  made  on  the  basis  of  the  collating 
sequence  of  the  character  set  used  in  a  given  implementation. 

Status  comparisons  will  be  made  on  the  basis  of  the  representation 
of  the  status  values. 

Pointer  comparisons  will  be  made  on  a  target-machine-dependent 
basis. 

For  bit  and  character  operands,  the  shorter  will  be  implicitly 
converted  to  the  type  of  the  longer  as  described  in  Section  7.0. 

Constraints : 


When  both  operands  are  <status-constants>,  at  least  one  must  be 
unambiguously  associated  with  a  single  status  type. 

When  the  two  operands  are  <status-formulas>,  their  types  must  be 
identical. 

When  the  two  operands  are  <pointer-formulas>,  their  types  must  be 
identical  or  one  must  be  an  untyped  pointer. 

When  both  operands  are  <fixed  formulas>,  there  must  exist  a  type  to 
which  both  operands  are  implicitly  convertible. 


2  5.2.2  BOOLEAN  FORMULAS 
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Syntax: 

<boolean— formula>  <bit-formula>  (5.2) 

Semantics: 


A  <boolean-formula>  la  a  <bit-formula>  whose  size  is  one  bit.  It 
has  the  value  TRUE  if  the  value  of  the  bit  is  one  and  FALSE  otherwise. 

Constraints: 

In  contexts  syntactically  requiring  a  <boolean-formula> 
(<if-statements>,  <while-phrases> ,  and  <trace-controls» ,  a 
<bit-f ormula>  cannot  be  implicitly  converted  to  a  <boolean-formula>. 


5.3  CHARACTER  FORMULAS 
Syntax: 

<charaeter-fonnula>  <character~literal>  (8.3.4) 

I  <character-variable> 

|  <named-character-constant> 

|  <character-function-call> 

|  (  <character-formula>  ) 


|  <character-conversion>  (7.0) 

(  <formula>  )  (5.0) 

<character-varlable>  : :■  <variable>  (6.1) 

<named-character-constant>  <named-constant>  (6.2) 

<character-funetlott-call>  : <function-call>  (6.3) 

<compile-time-character-formula>  : :*  <character-formula> 

Semantics : 


A  <character-formula>  represents  a  value  whose  type  class  is 
character.  Its  size  is  the  number  of  bytes  comprising  its  value. 
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Constraints: 

A  <character-varlable>  oust  be  a  <varlable>  whose  type  class  Is 
character. 

A  <naaed-character- constant>  must  be  a  <named-constant>  whose  type 
class  is  character. 

A  <character-function-call>  must  be  a  <functlon-call>  whose  result 
value  is  character. 

A  < compile- time— character-formula>  must  be  a  <character-formula> 
whose  value  is  known  at  compile  time  (see  Section  5.0). 

5.4  STATUS  FORMULAS 
Syntax: 

<status-fozmula>  ::■  <status-constant>  (2. 1.1. 6) 

|  <status-variable> 

I  <named-status-constant> 

|  <status-function-call> 

I  (  <status-formula>  ) 


|  <status-conversion>  (7.0) 

(  <formula>  )  (5.0) 

<status-variable>  : :*  <variable>  (6.1) 

<named-8tatus-constant>  <named-constant>  (6.2) 

<status-functlon-call>  <function-call>  (6.3) 

<compile-tlme-status-formula>  <status-formula> 

Semantics: 


A  <status-formula>  represents  a  value  whose  type  class  is  status. 
Constraints: 

A  <status-varlable>  must  be  a  <varlable>  whose  type  class  is 
status. 
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A  <named-status-constant>  muse  b«  a  <named-constant>  whoaa  type 
class  is  status. 

A  <status-function-call>  oust  be  a  <function-call>  whose  result 
value  Is  status. 

A  <compile-tima-status-formula>  must  be  a  <status-formula>  whose 
value  Is  known  at  compile  time  (see  Section  S.0). 

5.5  POINTER  FORMULAS 
Syntax: 

<pointer—f ormula>  <pointer-literal>  (8.3.5) 

|  <pointer-variable> 

|  <named-pointer-constant> 

I  <pointer-function-call> 

I  (  <pointer-formula>  ) 


|  <pointer-conversion>  (7.0) 

(  <formula>  )  (5.0) 

<pointer-variable>  :  <variable>  (6.1) 

<named-pointer— cons  tant>  <named-constant>  (6.2) 

<pointer-function-call>  : <function-call>  (6.3) 

<compile-time-pointer-f  ormula>  :  :■  <pointer-f  oraula> 

Semantics: 


A  <pointer~formula>  represents  a  value  whose  type  class  is  pointer. 
Constraints : 

A  <pointer-variable>  must  be  a  <variable>  whose  type  class  is 
pointer. 

A  <named-pointer-constant>  must  be  a  <named-constant>  whose  type 
class  is  pointer. 

A  <pointer-function-call>  must  be  a  <function-call>  whose  result 
value  is  pointer. 


89 


MIL- STD- 158 9 B  (USAF) 
06  June  1980 


A  <coopile— time— point er-formula>  oust  be  a  < point er—formula>  whose 
value  is  known  at  compile  time  (see  Section  5.0). 

5.6  TABLE  FORMULAS 
Syntax: 

<table-formula>  :  :*  <table-varlable> 

9 

I  <named-table-constant> 

I  (  <table-foroula>  ) 


t  <table-converslon>  (7.0) 

(  <formula>  )  (5.0) 

<table-varlable>  <varlable>  (6.1) 

<named-table-constant>  <named-constant>  (6.2) 

Semantics: 


A  <table-fonnula>  represents  a  value  whose  type  class  is  table. 
Constraints : 

A  <table-varlable>  must  be  a  <variable>  whose  type  class  is  table. 

A  <named-table-constant>  must  be  a  <named-constant>  whose  type 
class  Is  table. 


90 


MIL-STD-1589B  (USA F) 
06  June  1980 


6.0  DATA  REFERENCES 
6.1  VARIABLES 
Syntax; 


<variable> 

•  •  M 

•  • 

<namd-varlable> 

1 

<b i t-f unct i on-var i abl«> 

1 

<byt  e- f unc  t ion-va  rlable> 

1 

<rep-function-variable> 

1 

<function-name> 

(3.2) 

<naned-variable> 

* 

•  • 

<lten> 

1 

<table> 

1 

<table-item> 

1 

<table-entry> 

1 

<block-item> 

1 

<block-table> 

1 

<block-table-item> 

1 

<block-table-entry> 

<item> 

;  :• 

<item-name> 

(2.1.1) 

1 

<item-dereference> 

<table> 

•  •  M 

•  • 

<table-name> 

(2.1.2) 

1 

<table-dereference> 

<table-itea> 

•  •  ® 

<table-iteo-name> 

[<subscrlpC>] 

[<table-dere£erence>] 

(2. 1.2.3) 

<table-«ntry> 

* 

•  • 

<table-nane> 

<subscrlpt> 

(2.1.2) 

1 

<cable-deref ar«nce> 
<subscrlpt> 
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<block-lten> 

•  •  MB 

•  •  * 

<item-name> 

[ <block-deref erence> ] 

(2.1.1) 

<block-table> 

•  •  mm 

•  •  ™ 

<table-name> 

[<block-d«reference>] 

(2.1.2) 

<block-table-item> 

•  ■  H 

•  •  * 

<table-item-name> 

[<8ubscrlpt>] 

[ <block-deref erence> ] 

(2. 1.2.3) 

<block-table-entry> 

*  a  — 

•  • 

< table- name> 

<subserlpt> 

[ <block-deref er ence> ] 

(2.1.2) 

<block-dereference> 

•  ♦  1 
•  a" 

<dereference> 

<i tem-dereference> 

•  a™ 

<dereference> 

<table-dereference> 

:  :■ 

<dereference> 

<dereference> 

*  a  a 
a  a™ 

@  <pointer-iteo-name> 

\ 

@  (  <pointer-formula>  ) 

(5.5) 

<pointer-item-naa«> 

a  *• 

<item-name> 

(2.1.1) 

I 

< t able-i t en-name> 

(2. 1.2.3) 

1 

<cons tant-1 tea-name> 

(2.1.3) 

<subscrlpO 

(  <lndex>,...  ) 

(5.1.1) 

<index> 

a  a™ 

< lnt ege r-f o rmula> 

(5.1.1) 

1 

<status-foroula> 

(5.4) 

<bit-function-variable> 

*  a  m 

•  • 

BIT  (  <bit-variable>  , 
<fbit>  ,  <nbit>  ) 

(5.2) 

(6.3.3) 

<byte-function-varlable> 

•  m 

•  a 

BYTE  ( 

<charactar-variable>  , 
<fbyte>  ,  <nbyte>  ) 

(5.3) 

(6.3.4) 

<  rep-f unc t ion-va rlabl e> 

•  a 

•  • 

< rep-c onvers lon> 

C  <naaed-varlable>  ) 

(7.0) 
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Semantics: 

A  <varlable>  designates  a  data  object  whose  value  can  be  changed  by 
assignment.  A  <named-varlable>  designates  a  data  object  whose  value  can 
be  used  in  a  formula  and  changed  by  assignment.  A  <dereference> 
designates  the  data  object  whose  address  Is  contained  In  the 
<pointer-itemrname>  or  <pointer-formula>  of  the  <dereference>. 

An  <ltem>  variable  designates  either  an  object  declared  in  an  item 
declaration  or  an  object  pointed  to  by  a  typed  pointer  whose  type-name 
attribute  is  an  item  type.  In  the  latter  case  the  item  is  referenced 
with  an  <ltem-dereference>  (i.e.,  the  pointer  is  dereferenced  to  obtain 
the  item) . 

A  <table>  variable  designates  either  an  object  declared  in  a  table 
declaration  or  an  object  pointed  to  by  a  typed  pointer  whose  type-name 
attribute  is  a  table  type.  In  the  latter  case  the  table  is  referenced 
with  a  <table-dereference>  (i.e.,  the  pointer  is  dereferenced  to  obtain 
the  table).  The  type  class  of  a  <table>  is  table. 

A  <table— item>  variable  designates  an  item  component  of  a  table. 
If  the  table  is  dimensioned,  the  subscript  indicates  from  which  entry 
the  item  is  to  be  obtained.  If  <table-ltem-name>  was  declared  in  a 
<table-type-declaratlon>  (rather  than  a  <table-item-declaration>)  the 
<table-dereference>  references  the  particular  table  from  which  the  item 
is  to  be  obtained. 

A  <table-entry>  variable  designates  an  entry  in  a  dimensioned 
table.  The  table  is  referenced  either  with  a  <table-name>  or  with  a 
<table-deref erence> . 

The  type  class  of  a  <table-entry>  is  table  for  entries  declared 
with  an  <ordinary-table-body> ,  <specified-table-body>,  or 
<table-type-name>,  and  otherwise  is  the  type  specified  by  the  underlying 
<item-type-description>.  (Note  that  <table-entry>  is  syntactically  a 
subscripted  <table-name>  or  <table-dereference>.) 

If  the  type  class  of  a  particular  <table-entry>  is  not  table,  any 
operation  or  intrinsic  function  except  LOC,  NWDSEN,  and  REP  applied  to 
that  entry  is  interpreted  as  applying  to  the  item  whose  type  class  and 
attributes  are  given  by  the  underlying  <item-type-description>.  LOC, 
NWDSEN,  and  REP  are  interpreted  as  applying  to  the  entire  physical  space 
occupied  by  the  object,  including  filler  bits  preceding  or  following  the 
item. 


A  <block-item>  variable  designates  an  item  component  of  a  block. 
If  the  <itea-name>  was  declared  in  a  <block-type-declaration>,  the 
<block-dereference>  references  the  particular  block  from  which  the  item 
is  to  be  obtained. 
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A  <block-table>  variable  designates  a  table  coaponent  of  a  block. 
If  the  <table-name>  was  declared  In  a.  <block-type-dedaration>,  the 
<block-dereference>  references  the  particular  block  from  which  the  table 
is  to  be  obtained. 

A  <block-table-item>  variable  designates  an  item  component  of  a 
table  which  is  itself  a  component  of  a  block.  If  the  table  is 
dimensioned,  the  subscript  indicates  from  which  entry  the  item  is  to  be 
obtained.  If  the  < table- i t em-name>  was  declared  in  a  <block-type- 
declaratlon> ,  the  <block-dereference>  references  the  particular  block 
from  which  the  item  is  to  be  obtained.  (Note  that  if  the 
<table-item-name>  was  declared  in  a  <table-type-declaration>,  it  cannot 
be  obtained  as  a  <block-table-item>  variable  but  must  be  obtained  as  a 
<table-item>  variable  with  a  <table— dereference> .) 

A  <block- table-entry >  variable  designates  an  entry  in  a  dimensioned 
table  which  is  contained  in  a  block.  If  the  <table-name>  was  declared 
in  a  <block-type-declaration> ,  the  <block-dereference>  references  the 
particular  block  from  which  the  table  entry  is  to  be  obtained. 

A  <bit-functlon-varlable>  is  the  use  of  the  BIT  function  in  an 
assignment  context  (i.e.,  the  target  of  an  assignment  statement  or  an 
actual  output  parameter)  to  designate  that  a  specified  substring  of  the 
<blt-varlable>  is  to  be  used  as  a  variable.  <Fblt>  indicates  the 
starting  bit  and  <nblt>  indicates  the  size  of  the  substring.  Bits  are 
numbered  from  the  left  beginning  with  zero. 

A  <byte-function-variable>  is  the  use  of  the  BYTE  function  in  an 
assignment  context  (i.e.,  a  target  of  an  assignment  statement  or  an 
actual  output  parameter)  to  designate  that  a  specified  substring  of  the 
<character-variable>  is  to  be  used  as  a  variable.  <Fbyte>  indicates  the 
starting  character  and  <nbyte>  indicates  the  size  of  the  substring. 
Characters  are  numbered  from  the  left  beginning  with  zero. 

A  <rep-function-variable>  is  the  use  of  the  <rep-converslon>  in  an 
assignment  context  (i.e.,  the  target  of  an  assignment  statement  or  an 
actual  output  parameter)  to  designate  that  the  <named-varlable>  is  to  be 
treated  as  a  bit  string  variable  whose  size  is  the  number  of  bits  of 
storage  actually  occupied  by  the  <named-varlable>. 

Constraints : 

A  <subscrlpt>  must  be  present  in  a  <table-item>  or 
<block-table-ltem>  if  the  type  of  the  table  is  dimensioned. 

A  <subscrlpt>  in  a  <table-item>,  <table-entry>,  <block-table-item>, 
or  <block-table-entry>  must  contain  the  same  number  of  <indices>  as 
there  are  <dimenslons>  in  the  <dimension-list>  of  the  declaration  of  the 
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cable's  type.  Furthermore,  Che  type  of  each  <lndex>  must  be  Che  same  as 
the  type  of  Che  corresponding  <dimension>  and  Che  value  of  each  Index 
must  be  within  the  bounds  specified  for  chac  dimension.  If  the 
designated  Cable  is  a  formal  parameter  and  che  <dimensions>  were 
specified  as  *,  che  indices  muse  be  <integer-formulas>  (even  if  bounds 
of  an  actual  parameter  on  a  particular  invocation  are  of  status  type) , 
and  che  value  of  each  index  must  be  in  the  range  0  through  NN-1 ,  where 
HN  is  the  number  of  elements  in  that  dimension  of  the  actual  parameter. 

If  the  <table-item-name>  in  a  <table-item>  was  declared  in  a 
<table-type-declaration> ,  Che  '<table-item>  must  contain  a  <table- 
dereference>  whose  pointer  is  of  the  appropriate  type. 

If  the  <itea-name>  in  a  <block-item>  was  declared  in  a 
<block-type-declaration>,  the  <block-item>  must  contain  a  <block- 
dereference>  whose  pointer  is  of  the  appropriate  type. 

A  reference  to  a  <table-item>  must  not  access  storage  outside  the 
bounds  of  the  table  containing  that  <table-item>. 

If  the  <table-name>  in  a  <block-table>  or  <block-table-entry>  was 
declared  in  a  <block-type-dedaration> ,  the  <block-table>  or 
<block-table— entry >  must  contain  a  <block-dereference>  whose  pointer  is 
of  che  appropriate  type. 

If  the  <table-item-name>  in  a  <block-table-item>  was  declared  in  a 
<block-type-declaration>,  the  <block-table-item>  must  contain  a 
<block-dereference>  whose  pointer  is  of  the  appropriate  type. 

<Fbit>  and  <nbit>  must  not  designate  a  substring  beyond  the  bounds 
of  the  <bit-variable>.  <Nbit>  must  be  greater  than  zero. 

<Fbyte>  and  <nbyte>  must  not  designate  a  substring  beyond  the 
bounds  of  the  <character-varlable> .  <Nbyte>  must  be  greater  than  zero. 

A  <function-name>  can  be  used  as  a  <variable>  only  within  the  body 
of  a  function  having  that  <f unction-name> ,  and  then  only  as  che 
left-hand  side  of  an  assignment  statement.  The  other  valid  uses  of 
<functlon-name>  are  described  in  Section  3.2. 

A  pointer  to  an  undimensioned  parallel  or  tight  cable  type  cannot 
be  used  in  a  <deref erence> . 

The  value  of  a  pointer  used  in  a  <dereference>  must  be  in  the 
implementation-defined  set  of  valid  values  for  pointers  of  its  type.  A 
pointer  whose  value  is  NULL  cannot  be  dereferenced. 

r 
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6.2  NAMED  CONSTANTS 


Syntax: 


<named-constant> 

: :■  <constant-item-name> 

(2.1.3) 

• 

t  <constant-table— name> 

(2.1.3) 

|  <constant-table-item-name> 

[<subscript>] 

(6.1) 

|  <constant-table-name> 

(2.1.3) 

<subscript> 

(6.1) 

|  <control-letter> 

(4.2) 

<constant-table-item-name> 

:  <table-item-name> 

(2. 1.2.3) 

Semantics : 

A  <named-constant>  designates  a  constant  data  object  whose  value 
can  be  used  in  a  formula  but  cannot  be  changed. 

A  <constant-item-name>  designates  an  object  declared  in  a  constant 
item  declaration. 

A  <cons  tant-table-name>  designates  an  object  declared  in  a  constant 
table  declaration. 

A  <constant-table-item-name>  designates  an  item  component  of  a 
constant  table.  If  the  table  is  dimensioned,  the  <subscrlpt>  indicates 
from  which  entry  the  item  is  to  be  obtained. 

A  <constant-table-name>  followed  by  a  <subscript>  designates  an 
entry  in  a  dimensioned  constant  table. 

A  <control-letter>  designates  an  object  created  in  a  <for-clause> 
whose  <control-*ltem>  is  a  single  letter. 

Constraints: 

A  <subscript>  must  follow  a  <constant-table-item-name>  if  the  table 
is  dimensioned. 

A  <subscript>  following  a  <constant-table-item-name>  or  <constant- 
table-name>  must  contain  the  same  number  of  <indlces>  as  there  are 
<dimensions>  In  the  <dimension-list>  in  the  declaration  of  the  table. 
Furthermore,  the  type  of  each  <index>  must  be  the  same  as  the  type  of 
the  corresponding  <dimension>  and  the  value  of  each  <index>  must  be 
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within  the  bounds  specified  for  that  <dimension>. 

Constant  tables  and  items  selected  from  constant  tables  via 
subscripts  cannot  be  used  as  compile-time  values, 

A  <control-letter>  may  be  referenced  only  within  the 
<controlled-statement>  of  a  <loop-statement>  whose  <for-clause>  created 
that  <control-constant>. 

6.3  FUNCTION  CALLS 
Syntax: 


<function-call>  s  •" 

<user-defined-f unction— call> 

1 

<intrinsic-function-call> 

1 

<maehine-specific-function-call> 

<user-defined-function-call>:  :■ 

<function-name> 

I <actual-parameter-list> ] 

(3.2) 

(4.5) 

<int  r ins ic- f unc  t ion-call>  : 

<loc-function> 

(6.3.1) 

1 

<next-function> 

(6.3.2) 

1 

<bi t-f unction> 

(6.3.3) 

1 

<byte— f unction> 

(6.3.4) 

1 

<shift-function> 

(6.3.5) 

l 

<abs-functior»> 

(6.3.6) 

1 

<sign-function> 

(6.3.7) 

1 

<size-function> 

(6.3.8) 

<bounds-function> 

(6.3.9) 

1 

<nwdsen-function> 

(6.3.10) 

1 

<status-inverse-function> 

(6.3.11) 

<machine-specific-function- 

call>  :  s- 

<f  unction-name> 

[ <ac  t  ual-pa  rame  t  e  r-li s t> ] 

(3.2) 

(4.5) 
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Semantics: 

Execution  of  a  <function-call>  causes  invocation  of  a  function. 
Any  actual  parameters  are  bound  to  the  corresponding  formal  parameters 
as  described  in  Section  3.3. 

A  <user-defined-function-call>  causes  invocation  of  a  function 
defined  in  a  <function-definition>.  The  type  of  the  value  returned  by 
the  function  is  the  type  specified  by  the  <item-type-description>  in  the 
<functlon-heading>  of  the  <functlon-definition>. 

An  <intrinsic-function-call>  causes  invocation  of  a  language- 
defined  function.  A  description  of  the  language-defined  functions  is 
contained  in  the  following  sections.  The  type  of  the  value  returned  by 
each  function  is  described  in  the  corresponding  section. 


invocation  of  a 


A  <machine-specific-function-call>  < 
machine-specific  function  (see  Section  3.S). 

Constraints : 


Actual  parameters  in  the  <function-call>  must  match  the  formal 
parameters  of  the  called  function  in  number,  type,  and  parameter  list 
position  according  to  the  rules  given  in  Section  3.3. 


6.3.1  LOC  FUNCTION 


Syntax: 

<loc-function> 

<loc-argument> 


:■  LOC  (  <loc-argument>  ) 
<named-variable> 

|  <block-name> 

|  <statement-name> 

I  <procedure-name> 

I  <function-name> 

|  <block-deref erence> 


(6.1) 

(2.1.4) 

(4.0) 

(3.1) 

(3.2) 

(6.1) 


Semantics: 


The  LOC  function  can  be  applied  to  the  <loc-argument>  to  obtain 
the  machine  address  of  the  word  in  which  the  <loc-argument>  is  .tored. 
If  the  <loc-argument>  is  a  <named-variable>  or  <block-name>  that  was 
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declared  wich  a  <type-name>  TT,  che  type  of  the  value  returned  by  Che 
LOC  function  is  P  TT  (i.e.,  a  typed  pointer).  Otherwise,  the  type  of 
the  value  returned  by  the  LOC  function  la  P  (i.e.,  an  untyped  pointer). 

If  the  <loc-argument>  is  a  <statement-name>,  <procedure-name> ,  or 
<function-name>  the  <loc-function>  yields  an  untyped  pointer  whose  value 
is  the  machine  address  used  to  access  the  designated  statement  or 
subroutine. 

Constraints: 


The  LOC  of  a  subroutine  whose  name  appears  in  an 
<inline-declaration>,  or  of  a  <statement-name>  whose  definition  appears 
in  such  a  subroutine,  is  implementation-defined. 

Note: 


The  LOC  function  cannot  be  applied  to  an  intrinsic  function. 


6.3.2  NEXT  FUNCTION 
Syntax: 

<next-function> 

<next-argument> 

< incr  ement-amount> 


: NEXT  ( 

<next-argument>  , 

<increment-amount>  ) 

: <pointer-formula>  (5.5) 

|  <status-formula>  (5.4) 

<integer-formula>  (5.1.1) 


Semantics: 

If  che  <next-argument>  is  a  <pointei -formula> ,  the  value  returned 
by  the  NEXT  function  is  the  arithmetic  sum  of  the  representation  of  the 
<pointer-formula>  plus  the  <increment-amount>  *  LOCSINWORD  (i.e.,  the 
<pointer-formula>  is  treated  as  an  integer).  The  type  of  the  value 
returned  is  a  pointer  of  the  same  type  as  the  <next-argument>. 

If  the  <next-argument>  is  a  <status-formula>  and  the  value  of  che 
<increment-‘amount>  is  N,  the  value  returned  by  the  NEXT  function  is  the 
Nth  successor  (or  predecessor  if  N  is  negative)  of  the  value  of  the 
<status-formula>  in  this  <status-li5t>.  The  type  of  the  value  is  the 
same  as  the  type  of  the  <next-arguoent> . 
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Constraints : 


The  <next-argument>  cannot  be  a  <status-constant>  that  belongs  to 
more  than  one  status  type  (unless  explicitly  disambiguated  with  a 
<status-converslon» ,  nor  can  it  be  the  <pointer-literal>  NULL. 

The  type  of  the  <status-formula>  must  be  a  status  type  with  a 
default  representation. 

When  the  <next-argument>  is  a  <status-formula>,  the  . 
<increment-amount>  must  not  cause  the  NEXT  function  to  return  a  value 
out  of  range  of  the  type  of  the  <next-argument> . 

The  value  of  the  <polnter-formula>  and  the  value  of  the  pointer 
result  must  be  in  the  implementation-defined  set  of  valid  values  for 
pointers  of  its  type. 

Note: 


The  value  of  the  <next-argument>  may  be  negative. 


6.3.3  BIT  FUNCTION 
Syntax; 


<bit-function> 

:  :*  BIT  (  <bit-foraula>  , 
<fbit>  ,  <nbit>  ) 

(5.2) 

<fbit> 

:  :■  <integer-f ormula> 

(5.1.1) 

<nbit> 

:  :■  <integer-formula> 

(5.1.1) 

Semantics: 

The  BIT  function  selects  a  designated  substring  from  the 
<bit-formula>.  <Fblt>  indicates  the  starting  bit  and  <nbit>  indicates 
the  size  of  the  substring.  Bits  are  numbered  from  the  left  beginning 
with  zero.  The  type  of  the  value  returned  is  a  bit  string  of  the  same 
size  as  the  <bit-formula>.  The  designated  substring  is  right  justified 
in  Che  result  and  padded  on  the  left  with  zero  bits  as  necessary  to  fill 
the  size. 

Constraints: 


<Fbit>  and  <nbit>  must  not  designate  a  substring  beyond  the  bounds 
of  the  <bit-formula>.  <Nblt>  must  be  greater  than  zero. 
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6.3.4  BYTE  FUNCTION 

Syntax: 

<byt  e-f  unct ion> 

: :•  BYTE  (  <character-foraula>  , 
<fbyte>  ,  <nbyte>  ) 

(5.3) 

<fbyte> 

: :■  <lnteger-formula> 

(5.1.1) 

<nbyte> 

::■  <integer-formula> 

(5.1.1) 

Semantics: 

The  BYTE  function  selects  a  designated  substring  froa  the 
<character-formula>.  <Fbyte>  indicates  the  starting  character  and 
<nbyte>  indicates  the  size  of  the  substring.  Characters  are  numbered 
froa  the  left  beginning  with  zero.  The  type  of  the  value  returned  is  a 
character  string  of  the  same  size  as  the  <character-foraula>.  The 
designated  substring  is  left  justified  in  the  result,  and  padded  on  the 
right  with  blanks  as  necessary  to  fill  the  size. 

Constraints: 

<Fbyte>  and  <nbyte>  aust  not  designate  a  substring  beyond  the 
bounds  of  the  <character-formula>.  <Nbyte>  must  be  greater  than  zero. 


6.3.5  SHIFT  FUNCTIONS 
Syntax: 

: :»  <shif t-direction> 

(  <bit-fonnula>  , 

<shift-count>  )  (5.2) 

: :-  SHIFTL 

I  SHIFTR 

: :■  <integer-f ormula>  (5.1.1) 

Semantics: 

The  SHIFTL  function  performs  a  logical  left  shift  of  the 
<bit-formula>  by  the  number  of  positions  indicated  by  <shif t-count> . 
The  SHIFTR  function  performs  a  logical  right  shift  of  the  <bit-formula> 
by  the  number  of  positions  indicated  by  <shif t-count>.  In  both  cases, 
vacated  bits  are  filled  with  zeros  and  bits  shifted  out  are  lost.  If 
the  <shif t-count>  is  greater  chan  or  equal  to  the  size  of  the 


<shift-function> 


<shif t-direct ion> 


<shif t-count> 


101 


MIL-STD-1589B  (USAF) 
06  June  1980 


<bit-formula>,  Che  result  is  a  bit  string  with  all  zero  bits.  The  type 
of  the  value  returned  by  a  <shif t-function>  is  the  same  as  the  type  of 
the  <blt-formula> . 

Constraints : 

The  value  of  <shif t-count>  must  be  non-negative  and  less  than  or 
equal  to  MAXBITS. 

6.3.6  ABS  FUNCTION 
Syntax: 

<abs-functlon>  ABS  (  <numeric-formula>  )  (S.l) 

Semantics : 

The  ABS  function  produces  a  value  that  is  the  absolute  value  of  the 
<numeric-f ormula> .  The  result  is  equivalent  to  “  <numeric-formula>  if 
<numeric-formula>  is  negative  and  equivalent  to  +  <numeric-*formula> 
otherwise . 

6.3.7  SIGN  FUNCTION 
Syntax: 

<sign-function>  SGN  (  <numerlc-formula>  )  (5.1) 

Semantics: 

The  SGN  function  returns  a  value  according  to  the  following  rules: 


Numeric  Formula  Value 

>0  -*-1 

-  0  0 

<0  -1 


The  type  of  the  value  is  S  1. 
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6.3.8  SIZE  FUNCTIONS 


:  :■  <size-type> 

(  <size-argument>  ) 

:  s-  BITSIZE 

I  BYTES I ZE 

|  WORD SIZE 

<formula>  (5.0) 

|  <block-name>  (2.1.4) 

I  <type-name>  (2. 1.1. 7) 


The  BITSIZE,  BYTES I ZE  and  WORDSIZE  functions  return  the  logical 
size  of  the  <slze-argument>  in  bits,  bytes,  and  words  respectively.  The 
type  of  the  value  returned  is  S  MAXINTSIZE.  The  logical  BITSIZE  of  each 
data  type  in  the  language  will  be  described  below.  The  logical  BYTESIZE 
is  equal  to  BITSIZE/ BITSINBYTE  if  BITSIZE  MOD  BITSINBYTE  -  0  and 
BITSIZE/BITSINBYTE+1  otherwise.  Similarly,  the  logical  WORDSIZE  is 

equal  to  BITSIZE/ BITSINWORD  if  BITSIZE  MOD  BITSINWORD  -  0  and 

BITSIZE/BITSINWORD+1  otherwise. 

Bit:  The  BITSIZE  of  an  object  of  type  B  NN  is  NN 

Integer:  The  BITSIZE  of  an  object  of  type  U  NN  is  NN  and  S  NN 

is  NN+-1 

Fixed:  The  BITSIZE  of  an  object  of  type  A  MM,  NN  is 

MMH-NNH 

Float:  The  BITSIZE  of  a  float  object  is  the  number  of  bits 

of  storage  the  object  actually  occupies. 

Character :The  BITSIZE  of  an  object  of  type  C  NN  is 
NN*BITSINBYTE. 

Pointer:  The  BITSIZE  of  a  pointer  object  is  BITSINPO INTER. 

Status:  The  BITSIZE  of  a  status  object  is  the  <status~size>. 
If  <status-size>  was  specified,  the  BITSIZE  is  specified  in 
the  object's  <status-item-description>.  If  no  <status-size> 


Syntax: 

<s ize-f unct ion> 
<size-type> 

t 

<slze— argument> 

Semantics: 
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was  specified,  Che  BITSIZE  is  minimum  number  of  bics  of 
storage  needed  Co  represent  objects  of  that  type. 

Table:  The  BITSZZE  of  a  table  or  table  entry  chat  is  not 

tightly  structured  is  the  number  of  bits  from  the  leftmost  bit 
of  the  first  word  occupied  by  the  table  or  cable  entry  to  the 
rightmost  bit  of  the  last  word  occupied  by  the  table  or  table 
entry.  The  BITSIZE  of  a  tightly  structured  table  entry  is 
<bits-per-entry>.  The  BITSIZE  of  a  tightly  structured  table 
is  the  number  of  bits  from  the  leftmost  bit  of  the  first  word 
occupied  by  the  table  to  the  rightmost  bit  of  the  last  entry, 
where  the  last  entry  occupies  <bits-per-entry>  bits.  Note: 
the  BITSIZE  of  a  <table-entry>  whose  type  class  is  not  table 
is  the  BITSIZE  of  the  item  specified  by  the  underlying 
<item-type-description> . 

Block:  The  BITSIZE  of  a  block  is  NN  *  BITSINWORD,  where  NN 

is  the  number  of  words  the  block  occupies. 

Constraints: 


A  BITSIZE  function  oust  not  be  applied  to  a  table  whose  size  in 
words^ exceeds  MAXINT( MAXINTS I ZE) /BITSINWORD. 

A  BYTES IZE  function  must  not  be  applied  to  a  table  whose  size  in 
words  exceeds  MAXINT(MAXINTSIZE) /BYTES INWORD . 


6.3.9  BOUNDS  FUNCTIONS 


Syntax: 

<bounds-f unction> 

<which-bound> 

<dlmension-number> 

Semantics: 


<which-bound> 

(  <table-name>  ,  (2.1.2) 

<dimension-nuober>  ) 

LBOUND 

UBOUND 

<coopile-time-int eger-f ormula>  (5.1.1) 


The  LBOUND  function  returns  the  lower  bound  of  the  specified 
dimension  of  the  designated  table.  The  UBOUND  function  returns  the 
upper  bound  of  the  specified  dimension  of  the  designated  table.  A 
<dimenslon— number>  of  zero  refers  to  the  leftmost  <dimension>  in  that 
table's  <dimension-list>;  a  <dimension-number>  of  one  designates  the 
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next-to-leftmost  <dimension>  in  Che  list,  etc.  The  type  of  the  returned 
value  will  either  be  an  integer  type  or  a  statue  type  depending  on  the 
declaration  of  the  designated  table.  If  the  table  is  a  formal  parameter 
with  a  *  dimension,  the  type  will  always  be  integer,  LBOUND  will  always 
return  zero,  and  UBOUND  will  return  NN-1,  where  NN  is  the  number  of 
elements  in  that  dimension  of  the  actual  parameter. 

Constraints: 

The  <dimension-number>  must  be  greater  than  or  equal  to  0  and  less 
than  the  number  of  dimensions  in  the  designated  table. 


6.3.10  NWDSEN  FUNCTION 
Syntax: 

<nwdsen-f unction>  : :•  NWDSEN  (  <nwdsen-argument>  ) 

<nwdsen-argument>  ::«  <table-name>  (2.1.2) 

I  <table-type-name>  (2.2) 

Semantics : 

The  NWDSEN  function  returns  the  number  of  words  of  storage 
allocated  to  each  entry  in  the  named  table  or  table  type.  The  return 
type  is  S  with  default  size. 


6.3.11  STATUS  INVERSE  FUNCTIONS 
Syntax: 

<status-inverse-function>  FIRST  ( 

<status-inverse-argumen>  ) 

I  LAST  ( 

<status-inverse-argument>  ) 

<status-inverse-argument>  <status-formula>  (5.4) 

I  <3tatus-type-name>  (2. 1.1. 6) 

Semantics: 

The  FIRST  function  gives  the  value  of  the  lowest-valued 
<status-constant>  in  the  <status-list>  associated  with  the 
<statu8-inverse-argument>.  The  LAST  function  gives  the  value  of  the 


105 


MIL-STD-1589B  (USAP) 

06  June  1980 

highest-valued  <status-constant>  in  the  <status-llst>  associated  with 
the  <status-inverse-arguaent>. 

The  return  value  has  the  type  Indicated  by  the 
<status-inverse-arguaent> . 
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7.0  TYPE  MATCHING  AND  TYPE  CONVERSIONS 
Syntax: 


<bi t-conve rs ion> 

•  *■ 

•  • 

<bit-type-conversion> 

\ 

<r ep-c onve r s ion> 

<bit-type-converaion> 

•  •  m 

0  • 

(*  <bit-type-description>  *) 

(2. 1.1.4) 

1 

<bi t-type-naoe> 

(2. 1.1.4) 

1 

B 

<integer-conver8ion> 

•  •  a> 

•  • 

(*  <integer-type-description>  *) 

(2. 1.1.1) 

1 

1 

<integer-type-name> 

S 

(2. 1.1.1) 

<floating-c  crave rsion> 

I 

*  *  IB 

•  • 

D 

(*  <floating-type-description>  *) 

(2. 1.1.2) 

1 

1 

<floating-type-name> 

tf 

(2. 1.1.2) 

<f ixed-conve  rs ion> 

1 

•  • 

r 

(*  <f Ixed-type-description>  *) 

(2. 1.1.3) 

l 

<f Ixed-type-name> 

(2. 1.1.3) 

<charac  t er-c  onve  rs ion> 

«  •  ™ 

(*  <character-type-descrlption>  * 

)(2. 1.1.5) 

l 

1 

<character-type-name> 

n 

(2. 1.1.5) 

<status-conversion> 

1 

•  m 

•  • 

u 

(*  <status-cype-na«e>  *) 

(2. 1.1.6) 

1 

<s  tatus-type-naoe> 

(2. 1.1.6) 

<pointer-conversion> 

:  :■ 

(*  <pointer-type-description>  *) 

(2. 1.1. 7) 

1 

<pointer-type-name> 

(2. 1.1. 7) 

I  P 
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<table-conversion>  (*  <table-type-name>  *)  (2.1.2) 

I  <table-type-nama>  (2.1.2) 

<rep-conversion>  :  :■  REP 

Semantics: 


In  Section  2.1 ,  the  definition  of  type  was  given.  In  some  cases, 
implicit  conversions  will  be  performed  to  achieve  type  equivalence.  In 
this  section,  for  each  type  class,  rules  will  be  given  regarding  when 
two  types  are  the  same,  when  an  object  of  one  type  will  be  implicitly 
converted  to  another  type,  and  when  and  how  an  object  of  one  type  can  be 
explicitly  converted  to  another  type.  Implicit  conversions  will  never 
be  performed  on  arguments  to  explicit  conversions  or  when  the  types  of 
the  data  objects  are  required  to  match  exactly.  With  all  the 
conversions  (both  implicit  and  explicit),  if  the  value  produced  after 
conversion  is  not  in  the  range  of  values  of  the  type  being  converted  to, 
the  conversion  is  illegal. 

For  purposes  of  type  equivalence,  a  user-defined  <type-name>  is 
considered  an  abbreviation  for  its  specification. 

A  <formula>  may  be  explicitly  converted  to  another  type  by 
enclosing  it  in  parentheses  and  preceding  it  with  appropriate 
conversion.  Note  that  if  the  conversion  does'  not  consist  of  a  single 
letter  or  name,  it  must  be  enclosed  in  (*  and  *). 

Omitted  attribute  specifiers  in  type  conversions  imply  the  same 
default  values  as  for  declarations  of  those  types. 

Type  equivalence  and  conversion  rules  for  each  of  the  J73  type 
classes  are  as  follows: 

Bit  (B) 

Type  Equivalence: 


Implicit  Conversions: 


Explicit  Conversions: 


Two  bit  types  are  equivalent  if  their  size 
attributes  are  equal. 

A  bit  string  will  be  implicitly  converted  to  a 
bit  string  with  a  different  size  attribute, 
with  truncation  on  the  left  or  padding  with 
zeros  on  the  left.  Implicit  truncation  is  not 
permitted  when  the  syntax  requires  a 
<boolean-f ormula> • 

Any  data  object  -  except  a  block  may  be 
explicitly  converted  to  a  bit  string  with  a 
<bit-conversion>.  A  <bit-conversion>  may  be 
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Integer  (S  and  U) 

Type  Equivalence: 

Implicit  Conversions: 


either  a  <bit-type-conversion>  or  a 
<r ep-c  onve  rs ion> . 

A  <bit-type-conversion>  to  a  type  B  NN  takes 
the  rightmost  NN  bits  of  the  data  object's 
representation.  If  there  are  fewer  than  NN 
bits,  the  object  will  be  padded  on  the  left 
with  zeroes.  The  default  value  for  NN  is  1.  A 
<bit-type-conversion>  may  be  applied  to  a  data 
object  of  any  type.  If  the  object  being 
converted  is  a  table  or  table  entry,  all 
"filler"  bits  (l.e.,  bits  that  contribute  to 
the  size  of  the  table  but  that  are  not  part  of 
the  component  objects'  sizes  as  declared)  are 
included  in  the  string.  If  the  object  to  be 
converted  is  of  type  class  character,  filler 
bits  between  bytes  and  unused  bytes  following 
the  end  of  the  string  are  not  included. 

A  <rep-converslon>  provides  a  means  of 
obtaining  the  representation  of  a  data  object. 
A  < r ep-c onve rslon>  treats  a  data  object  as  a 
bit  string  whose  size  is  the  number  of  bits 
actually  occupied  by  Che  object.  This  includes 
all  filler  bits  and  the  bits  in  the  unused  (but 
allocated)  bytes  following  the  ends  of 
character  strings.  For  all  objects  whose  type 
class  is  table,  the  number  of  bits  in  the  bit 
string  is  the  same  as  the  BITSIZE  of  the 
object.  For  all  <table-entries>  whose  type 
class  is  not  cable,  the  number  of  bits  in  the 
bit  string  is  the  total  number  of  bits 
(including  filler  bits)  in  the  cable  entry.  A 
<rep-conversion>  can  appear  in  the  target  of  an 
assignment  statement  (see  Section  6.1).  A 
<rep-conversion>  can  be  applied  to 
<named-varlables>  only;  further,  it  cannot  be 
applied  to  tables  declared  with  *  dimensions, 
to  entries  in  parallel  tables,  or  to  tables 
whose  size  in  bits  exceeds  MAXBITS. 


Two  Integer  types  are  equivalent  if  they  are 
both  S  or  U  and  if  their  size  attributes  are 
equal. 

An  integer  type  will  be  implicitly  converted  to 
any  ocher  integer  type. 
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Explicit  Conversions: 


Floating 


Type  Equivalence: 


An  <integer-converslon>  is  used  to  explicitly 
convert  a  data  object  to  an  integer  type.  The 
conversion  can  be  applied  to  objects  of  bit, 
integer,  fixed,  float,  and  pointer  only. 

A  bit  string  will  be  treated  as  representing 
the  value  of  the  integer  type  if  the  size  of 
the  bit  string  is  less  than  or  equal  to  the 
BITSIZE  of  the  integer  type.  Otherwise,  the 
conversion  is  illegal.  If  the  size  of  the  bit 
string  is  less  than  the  BITSIZE  of  the  integer 
type,  the  bitstring  will  be  padded  on  the  left 
with  zeroes. 

An  integer,  fixed,  or  floating  data  object  will 
be  converted  to  the  integer  type,  with 
truncation  or  rounding  if  specified. 

Converting  a  pointer  to  an  integer  type  is 
equivalent  to  first  converting  the  pointer  to 
type  B  BITSINPO INTER  and  then  converting  the 
bit  string  to  integer. 


Two  floating  types  are  equivalent  if  their 
precision  attributes  are  equal. 


Implicit  Conversions:  A  floating  type  will  be  Implicitly  converted  to 

a  floating  type  of  the  same  or  greater 
n^e^ision  regardless  of  the  round-or-truncate 
attribute.  A  <real-literal>  will  be  implicitly 
treated  as  a  <floating-literal>  in  the  contexts 
specified  in  Section  8.3.1.  (Implicit  floating 
conversions  do  not  change  numeric  values 
although  they  may  cause  a  change  in  how  the 
value  is  represented.) 

Explicit  Conversions:  A  <floating-conversion>  is  used  to  explicitly 

convert  a  data  object  to  a  floating  data  type. 
The  conversion  can  be  applied  to 
<real-llterals>  and  to  objects  of  bit,  integer, 
fixed,  and  float  types  only. 

A  bit  string  will  be  treated  as  representing 
the  value  of  the  floating  type  if  the  size  of 
the  bit  string  equals  the  BITSIZE  of  the 
floating  type.  Otherwise  the  conversion  is 
illegal. 
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Fixed  (A) 

Type  Equivalence: 

Implicit  Conversions: 


Explicit  Conversions: 


An  integer,  fixed,  or  floating  data  object  will 
be  converted  to  the  floating  type,  with 
truncation  or  rounding  as  specified  in  the 
<floatiqg-converslon>.  Sounding  and  truncation 
are  performed  with  respect  to  the  Implemented 
precision  of  the  type  specified  by  the 
<f loating-conversion> . 


Two  fixed  point  types  are  equivalent  if  their 
s' ale  attributes  are  equal  and  their  fraction 
attributes  are  equal. 

A  fixed  point  type  will  be  implicitly  converted 
r  an  ther  fixed  point  type  if  the  scale  and 
fraction  attributes  of  the  target  type  are  both 
at  least  as  large  as  those  of  the  source  type. 
A  <real-literal>  will  be  implicitly  treated  as 
a  <fixed-literal>  in  the  contexts  specified  in 
Section  8.3.1.  Implicit  fixed  conversions  do 
not  change  the  numeric  value  represented  except 
when  the  implemented  precision  of  the  result 
value  is  less  than  the  implemented  precision  of 
the  value  being  converted  (see  Section 
2. 1.1.3);  in  this  case,  rounding  or  truncation 
occurs  with  respect  to  the  Implemented 
precision  of  the  converted  value.  This 
situation  occurs  only  when  assigning  to  a 
packed  fixed  table  item  (in  an  assignment 
statement,  loop  <control-variable> ,  table 
preset,  or  output  parameter);  the 
<round-or-truncate>  attribute  of  the  table  item 
determines  whether  the  assigned  value  is 
~''unded  or  truncated. 

A  <fixed-conversion>  is  used  to  explicitly 
convert  a  data  object  to  a  fixed  point  data 
type.  The  conversion  can  be  applied  to 
<real-literal>  and  to  objects  of  bit,  integer, 
fixed,  and  float  types  only. 

A  bit  string  will  be  treated  as  representing 
the  value  of  the  specified  fixed  point  type  if 
the  size  of  the  bit  string  equals  the  BITSIZE 
of  the  fixed  point  type.  Otherwise,  the 
conversion  is  illegal. 
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Character  (C) 

Type  Equivalence: 

Implicit  Conversions: 

Explicit  Conversions: 


Pointer  (P) 

Type  Equivalence: 

Implicit  Conversions: 
Explicit  Conversions: 


An  integer,  fixed,  or  floating  data  object  will 
be  converted  to  the  specified  fixed  point  type, 
with  truncation  or  rounding  as  specified  in  the 
<flxed-conversion>.  Rounding  and  truncation 
are  performed  with  respect  to  the  implemented 
precision  of  the  type  specified  by  the 
<f ixed-c  onve  rs ion> . 


Two  character  types  are  equivalent  if  their 
size  attributes  are  equal. 

A  character  string  will  be  implicitly  converted 
to  a  string  with  a  different  size  attribute, 
with  truncation  on  the  right  or  padding  with 
blanks  on  the  right. 

A  <character-conversion>  is  used  to  explicitly 
convert  a  data  object  to  a  character  data  type. 
The  conversion  can  be  applied  to  objects  of 
A  type  bit  or  character  only. 

A  bit  string  will  be  treated  as  representing 
the  value  (excluding  filler  bits  between  bytes) 
of  the  character  type  if  the  size  of  the  bit 
string  equals  the  BITSIZE  of  the  character 
type.  Otherwise  the  conversion  is  illegal. 

A  character  string  will  be  converted  to  type  C 
NN  by  taking  the  leftmost  NN  characters.  If 
there  are  fewer  than  NN  characters,  the  value 
is  padded  on  the  right  with  blanks. 


Two  pointer  types  are  equivalent  if  they  are 
both  untyped  pointers  or  if  they  are  both  typed 
pointers  referring  to  the  same 
<type-declaration> . 

A  typed  pointer  will  be  implicitly  converted  to 
an  untyped  pointer. 

A  <pointer-conversion>  is  used  to  explicitly 
convert  a  data  object  to  a  pointer  type.  The 
conversion  can  be  applied  to  bit,  integer,  or 
pointer  data  objects  only. 
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Type  Equivalence: 


Implicit  Conversions: 
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A  bit  string  will  be  treated  as  representing 
the  value  of  the  pointer  type  if  the  size  of 
the  bit  string  equals  the  BITSIZE  of  the 
pointer  type.  Otherwise  the  conversion  is 
illegal. 

Converting  an  integer  to  a  pointer  is 
equivalent  to  first  converting  the  integer  to 
type  B  BITSINPOINTER  and  then  converting  the 
bit  string  to  a  pointer. 

Converting  a  pointer  to  a  different  pointer 
type  means  that  the  pointer  will  be  considered 
as  a  pointer  of  the  specified  type. 


Two  status  types  are  equivalent  if  (1)  they 
both  have  default  representation,  their  size 
attributes  are  the  same,  and  both 
<status-llsts>  contain  the  same  <status- 
constants>  in  the  same  order,  or  (2)  they  both 
have  identical  programmer-specified 
representations,  their  size  attributes  are  the 
same,  and  both  <status-lists>  contain  the  same 
<status-constants>.  . 

A  status  type  will  be  implicitly  converted  to  a 
status  type  that  differs  only  in  its  size 
attribute.  Furthermore,  a  status  constant 
belonging  to  more  than  one  status  type  is 
implicitly  disambiguated  in  the  following 
contexts:  (1)  when  it  is  the  source  value  of 
an  assignment  statement,  it  takes  the  type  of 
the  target  variable;  (2)  when  it  is  an  actual 
parameter,  it  takes  the  type  of  the 
corresponding  formal  parameter;  (3)  when  it  is 
in  a  table  <subscrlpt>  or 
<preset-index-specifier>,  it  takes  the  type  of 
the  corresponding  <dlmension>  in  that  table's 
declaration;  (4)  when  it  is  a  loop 
<initial-value> ,  it  takes  the  type  of  the 
<control-variable>;  (5)  when  it  is  in  an 
<item-preset>  or  <table-preset>.  It  takes  the 
type  of  the  item  or  table  item  being 
initialized;  (6)  when  it  is  an  operand  of  a 
<relational-operator> ,  it  takes  the  type  of  the 
other  operand;  (7)  when  it  is  in  a 
<case-index-group>,  it  takes  the  type  of  the 
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Explicit  Conversions: 


Table 

Type  Equivalence: 


<case-selector-formula>;  and  (8)  when  It  Is  a 
<lower-bound>  or  <upper-bound> ,  it  takes  the 
type  of  the  other  bound. 

A  <status-conversion>  Is  used  to  explicitly 
convert  a  data  object  to  a  status  type.  The 
conversion  can  be  applied  to  bit  or  status  data 
objects  only. 

A  bit  string  will  be  treated  as  representing 
the  representational  value  of  the  status  type 
if  the  size  of  the  bit  string  equals  the 
BITSIZE  of  the  status  type  and  the  value  of  the 
bit  string  is  within  the  range  of  values  of  the 
status  type.  Otherwise  the  conversion  is 
illegal. 

A  <status-conversion>  may  be  used  to  assert  the 
type  of  a  status  object.  This  will  be 
required  when  a  status  constant  belongs  to  more 
than  one  type  and  it  is  used  in  a  context  other 
than  these  enumerated  above  under  implicit 
conversions.  Except  for  status  objects  whose 
types  differ  only  in  their  size  attributes,  a 
status  object  cannot  be  converted  to  a 
different  status  type  without  first  converting 
it  to  a  bit  string. 


Two  table  have  equivalent  types  if  they  are 
both  ordinary  or  both  specified,  their 
<structure-specifier>  attribute  is  the  same, 
they  have  the  same  number  of  dimensions,  they 
have  the  same  number  of  elements  in  each 
dimension,  they  have  the  same  number  of  items 
in  the  same  textual  order  in  each  entry,  the 
types  (including  attributes)  of  the  items  are 
equivalent,  the  (explicit  or  implied)  packing 
specifier  on  each  of  the  items  is  the  same  (for 
ordinary  tables),  the  I0RDER  directive  is 
either  present  in  both  tables  or  absent  in  both 
tables,  the  <words-per- entry>  attribute  is  the 
same  (for  specified  tables),  and  the 
location-specifiers  of  the  items  are  the  same 
(for  specified  tables).  (Note  that  the  names 
of  the  items,  as  well  as  the  types  and  Sounds 
of  the  dimensions,  need  not  be  the  same.)  A 
table  entry  is  considered  to  have  no 
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dimensions.  A  Cable  whose  entry  contains  an 
item-declaration  is  not  considered  equivalent 
in  type  to  a  table  whose  entry  is  declared 
using  an  unnamed  item  description. 

Implicit  Conversions:  No  implicit  conversions  are  performed. 

Explicit  Conversions:  A  bit  or  table  data  object  may  be  explicitly 

converted  to  a  table  type  with  a  <table- 
converslon>. 

A  bit  string  will  be  treated  as  representing 
the  value  of  the  table  type  if  the  size  of  the 
bit  string  equals  the  BITSIZE  of  the  table 
type.  Otherwise  the  conversion  is  illegal. 

A  <table-conversion>  may  be  applied  to  a  table 
object  of  chat  type  merely  to  assert  its  type. 
(A  table  object  cannot  be  converted  to  a 
different  table  type  without  first  converting 
it  to  a  bit  string). 
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8.0  BASIC  ELEMENTS 
8.1  CHARACTERS 
Syntax: 

<character>  : <letter> 


|  <digit> 

I  <mark> 

I  <other-character> 


<letter> 

: :•  A 

1 

B 

1 

C 

1 

D 

E 

F 

1  G 

1 

H 

1 

I 

1 

J 

X 

L 

1  M 

1 

N 

1 

0 

1 

P 

Q 

R 

1  s 

1 

T 

1 

u 

1 

V 

w 

X 

1  Y 

1 

Z 

<digit> 

0 

1 

1 

1 

2 

1 

3 

4 

5 

1  6 

1 

7 

1 

8 

1 

9 

<mark> 

+ 

1 

- 

1 

* 

1 

/ 

> 

< 

1  - 

1 

e 

1 

• 

1 

: 

. 

; 

1  ( 

1 

) 

1 

/ 

1 

" 

z 

! 

1  $ 

1 

blank 

Semantics: 


The  text  of  a  J73  <complete-program>  Is  a  continuous  stream  of 
<characters>.  However,  in  some  contexts,  the  end  of  an  Input  record  has 
significance  (see  Section  8.2). 

Note  that  in  the  standard  character  set  for  the  language  <letters> 
are  defined  to  be  upper  case  letters  only.  <Marks>  are  used  either 
alone  or  in  conjunction  with  other  characters  as  operators,  delimiters, 
and  separators.  <Other-characters>  are  the  remaining  Implementation- 
dependent  characters,  which  are  accepted  within  <character-literals>  and 
<comments>,  and  which  may  also  be  used  as  described  below.  Each 
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implementation  must  define  these  characters,  as  well  as  the  ordering  of 
all  <characters>  in  a  collating  sequence. 

Some  of  the  standard  characters  are  not  universally  available; 
therefore,  the  following  standard  alternates  are  defined: 

Standard  Character  Alternates 

t  or  ? 

->  or  _ 

* 

V 


z 

If  any  of  the  above  standard  characters  are  unavailable  on  a  particular 
machine,  one  of  the  recommended  alternates  for  that  character  must  be 
used.  (The  first  column  of  alternates  is  intended  for  the  CDC  standard 
63  and  64  character  sets;  the  alternates  ?  and  _  are  intended  for  the 
Unlvac  1108.)  If  the  :  is  replaced,  the  Z  must  also  be  replaced. 

An  implementation  that  has  lower  case  letters  available  in  addition 
to  uppercase  may  permit  their  use  in  programs  provided  that  within 
<names>,  <reserved-words> ,  <letters>,  <status-constants>  and  all 
<literals>  except  <character-literals>  they  are  considered 
interchangeable  with  their  corresponding  uppercase  letters  (e.g.,  XX 
and  xx  denote  the  same  name);  whereas  within  <character-literals>  they 
are  considered  distinct. 

An  implementation  that  has  square  brackets  available  may  allow  [ 
to  be  used  for  (*  and  ]  to  be  used  for  *)  but  may  not  prohibit  the  use 
of  the  (*  and  *). 

Constraints : 

If  a  left  bracket  is  substituted  for  (*,  then  a  right  bracket  oust 
be  substituted  for  the  corresponding  *).  If  a  right  bracket  is 
substituted  for  *),  then  a  left  bracket  must  be  substituted  for  the 
corresponding  (*. 


0 

0 

•  I 

! 

Z 
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8.2  SYMBOLS 
Syntax; 
<symbol> 


Semantics: 


<name> 

<reserved-word> 

<operator> 

<llteral> 

<status-constant> 

<comment> 

<def ine-string> 
<define-call> 
<letter> 
<separator> 


(8.2.1) 

(8.2.2) 

(8.2.3) 

(8.3) 

(2. 1.1.6) 

(8.4) 

(2.4) 

(2.4.1) 

(8.1) 

(8.2.4) 


<Characters>  are  combined  into  <symbols>  to  form  the  vocabulary  of 
the  language.  <Symbols>  are  indivisible  units  and  cannot  contain 
blanks,  except  as  noted  in  Section  8.5.  Only  <comments>, 
<def ine-strings>,  define  parameters  enclosed  in  quotation  marks, 
<bit-literals>,  and  <character-literals>  may  extend  across  multiple 
input  records;  all  other  symbols  are  terminated  by  the  end  of  an  input 
record . 


8.2.1  NAMES 
Syntax: 

<name>  : <letter-or-$> 

<letter-digit-$-or-prime> . . . 

<letter-or-$>  ::■  <letter> 

I  $ 


<letter-digit-$-or-prime> 


<letter> 


(8.1) 
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|  <digit>  (8.1) 

I.  $ 

I  ' 

Semantics : 

\  <Names>  are  words  having  programmer-supplied  spellings.  <Names> 
are  used  to  denote  entitles  In  the  <completc-program>. 

Only  the  first  31  characters  of  a  J73  <name>  are  used  to  determine 
uniqueness.  Additional  characters  are  permitted,  but  are  ignored. 

For  external  names,  an  Implementation  may  further  restrict  the 
number  of  initial  characters  that  determine  uniqueness. 

A  dollar  sign  in  a  <name>  is  translated  to  an 
implementation-dependent  representation.  This  translation  of  the  dollar 
sign  permits  the  use  of  a  character  in  a  <name>  that  might  otherwise  be 
unrepresentable  in  the  language.  If,  for  example,  external  names  in  a 
given  system  were  prefixed  by  the  character  '.'a  J73  implementation  on 
that  system  might  choose  to  represent  '$'  when  it  occurs  in  a  name  by 
the  representation  for  '  .'  .  Thus,  the  name  '  $$ABC'  occuring  in  a 
source  program  would  be  translated  '..ABC'. 


8.2.2  RESERVED  WORDS 
Syntax : 

<reserved-word>  :  :=  ABORT  |  ABS  |  AND  |  BEGIN  I  BIT 

*  J  B1TSIZE  |  BLOCK  |  BY  |  BYREF 

|  BYRES  I  BYTE  |  BYTESIZE  |  BYVAL 
|  CASE  I  C0MP00L  I  CONDITION* 

|  CONSTANT  |  DEF  |  DEFAULT  |  DEFINE 
|  ELSE  |  ENCAPSULATION*  |  END  |  EQV 

|  EXIT  I  EXPORTS*  |  FALLTHRU  I  FALSE 
|  FIRST  I  FOR  |  FREE*  |  GOTO 

f 

|  HANDLER*  |  IF  |  IN*  |  INLINE 
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INSTANCE  |  INTERRUPT*  | 

ITEM 

LABEL 

|  LAST 

|  LBOUND  | 

LIKE 

LOC  | 

MOD  | 

NENT*  |  NEW* 

NEXT  | 

NOT  | 

NULL  | 

NWDSEN 

|  OR 

|  OVERLAY  | 

PARALLEL 

POS  | 

PROC  I 

PROGRAM  | 

PROTECTED* 

READONLY*  |  REC  |  REF  | 

REGISTER* 

RENT  | 

REP  | 

RETURN  | 

SGN 

SH1FTL 

|  SHIFTR  |  SIGNAL* 

START 

!  STATIC  |  STATUS 

|  STOP 

TABLE 

|  TERM 

|  THEN  | 

TO* 

TRUE  | 

TYPE 

|  U BOUND  | 

UPDATE* 

WHILE 

|  WITH* 

|  WORDSIZE 

WR1TE0NLY*  | 

XOR  |  ZONE* 

Semantics : 

<Reserved-words>  have  language-defined  meanings  and  cannot  be  used 
as  <naroes>. 


Those  reserved  words  followed  by  an  *  in  the  above  list  ■  are 
reserved  in  order  to  maintain  upward  compatibility  with  future 
extensions  to  the  language  and  currently  have  no  meaning  in  J73. 


8.2.3  OPERATORS 


Syntax; 

<opera'tor> 


<arithmetic-operator> 


<bit-operator> 


<relational-operator> 

•V 
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<arlthmeClc-operaCor> 


<plus-or-minus> 

<mult iply-divide-or-mod> 

<multiply»or-divide> 

<bit-operator> 

<logieal-operator> 

<relational-operator> 

<equal-or-not-equal-operator> 

<dereference-operator> 

<assignment-operator> 

Semantics: 


|  <deref erence-operator> 

|  <assignment-operator> 

: <plua-or-minua> 

I  <multiply-divide-“or-mod> 

|  <multiply-or-divide> 

I  ** 

+  |  - 

: *  |  /  |  MOD 

::-*!/ 

:  :■  <logical-operator> 

|  NOT 

AND  |  OR  I  XOR  I  EQV 

:  :•  <equal-or-not-equal-operator> 
I  <1  >1  <*  I  >“ 

-  |  <> 

:  :■  @ 


The  meanings  of  these  operators  are  given  in  Sections  4,  5,  and  6. 
The  order  of  combination  of  operators  and  operands  is  determined  by 
parentheses  and  by  the  operators'  precedence.  The  operation  implied  by 
an  operator  at  one  precedence  level  is  combined  before  the  operation 
implied  by  an  operator  at  a  lover  level.  Within  a  particular 
precedence  level,  operations  are  combined  from  left  to  right  if  the 
1LEFTR1GHT  directive  is  in  effect  and  in  an  implementation-dependent 
order  if  the  ! REARRANGE  directive  is  in  effect. 

Precedence  of  operators  is  defined  by  the  syntax  of  the  language 
and  is  summarized  below: 


/ 


/ 
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6  @,  subscripting,  function  calls 

5  ** 

4  *,  /,  MOD 

3  - 

2  <>,  <,  >,  <-,  >- 

1  NOT,  AND,  OR,  EQV,  XOR 

0  assignment 

8.2.4  SEPARATORS 
Syntax: 

<separator>  ::»  (  |  )  |  (*  |  *) 

I  s  I  ,  I  J  M 

Semantics: 

<Separators>  are  used  for  the  following  purposes  in  J73: 

(  )  Expression  grouping,  list  delimiters,  status 

constants,  position  brackets,  subscripts,  case 
labels 

(*  *)  Type  conversions 

:  Statement  name,  case  label,  and  preset  index 

terminator;  loop  control  separator;  overlay, 
dimension,  subrange,  and  parameter  separator 

,  List  separator 

;  Statement,  declaration,  and  directive  terminator 

!  Directive  indicator,  formal  define  parameter 

marker 
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8.3  LITERALS 
Syntax: 
<literal> 


Semantics : 


■  <numeric-literal>  (8.3.1) 
I  <bit-literal>  (8.3.2) 
I  <boolean-literal>  (8.3.3) 
I  <character-literal>  (8.3.4) 
I  <pointer-literal>  (8.3.5) 


<Literals>  are  data  objects  whose  value  and  type  are  Inherent  in 
the  form  of  the  <symbol>  itself.  Their  values  are  known  at  compile 
time,  and,  like  other  compile-time  values,  cannot  be  altered  during 
execution. 


8.3.1  NUMERIC  LITERALS 
Syntax: 


<numeric—literal> 

*  •  » 

•  • 

I 

1 

<integer-literal> 

<floating-literal> 

<fixed-literal> 

<integer-literal> 

::- 

<number> 

<number> 

:  :- 

<digit> ... 

(8.1) 

<floating-literal> 

:  :- 

< real-1 iteral> 

<real-literal> 

1 

<digit>...  <exponent> 

<fractional-form> 

[ <exponent> ] 

(8.1) 

<exponent> 

•  m 

•  • 

E  [<sign>]  <number> 

<sign> 

•  « 

•  • 

+  1  - 

<fractional-form> 

* 

•  • 

<digit>... 

(8.1) 
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I  [<digit>. ..]  .  <digit>...  (8.1) 

<flxed-literal>  <real-literal> 

Semantics: 

An  <integer-literal>,  LL, 'denotes  a  decimal  value.  Its  type  la  S 
NN,  where  NN  is  IMPLINTSIZE(MINSIZE(LL)) . 

The  type  of  a  <real-literal>  or  a  <real-literal>  preceded  by  a 
<slgn>  is  determined  by  the  context  in  which  the  literal  appears, 
namely: 

.  when  the  literal  is  used  as  a  preset  value,  it  is 

implicitly  converted  to  the  type  of  the  object  being 

preset; 

.  when  the  literal  is  used  as  an  assignment  value,  it  is 
implicitly  converted  to  the  type  of  the  target  being 

assigned  a  value; 

.  -when  the  literal  is  an  operand  of  an  infix  relational  or 
numeric  operator  and  the  other  operand  is  not  a 
real-literal,  it  is  converted  to  the  type  of  the  other 
operand; 

.  when  the  literal  is  an  actual  parameter,  it  is  converted 
to  Che  type  of  Che  formal  parameter; 

.  when  a  literal  is  the  <initial-value>  of  a  loop 

<control-dause> ,  it  is  converted  to  the  type  of  the 

<control-variable> ; 

.  when  the  literal  is  the  argument  of  an  explicit  fixed  or 
floating  conversion,  it  is  converted  to  the  specified 

type. 

If  the  type  of  an  optionally  signed  <real-literal>  is  not  determined 
contextually,  it  is  considered  to  be  a  floating  type  with  default 
precision. 

A  <real-literal>  denotes  a  decimal  value.  If  an  <exponent>  is 
present,  the  decimal  value  preceding  the  <exponent>  is  multiplied  by  10 
to  the  value  specified  in  the  <exponenc>. 

For  <real-llterals>,  non— <exponent>  digits  in  excess  of 
MAXSIGDIGITS  will  be  created  aa  zeroes  in  computing  the  fixed  or 
floating  value  to  be  represented. 
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Contextual  determination  of  the  type  of  a  real-literal  will  not  be 
affected  by  the  presence  or  absence  of  the  <rearrange-directive>. 


Constraints: 

<Real-llterals>  may  .  be  implicitly  converted  to  fixed  or  floating 
values  only. 

The  value  of  an  <integer-literal>  with  size  SS  must  not  exceed 
MAXINT(SS). 

The  value  of  a  <floatlng-literal>  with  precision  PP  must  not  exceed 
MAXFLOAT(PP) . 


The  value  of  a  <f ixed-literal>  with  scale  SS  and  fraction  FF  must 


not  exceed  MAXFIXED( SS,FF) . 

Examples : 

ITEM  FF  F  24  -  -0.1; 

ITEM  RR  F,R  24  -  -0.1; 

ITEM  TT  F,T  24  -  -0.1; 

CONSTANT  ITEM  CC  F,R  24  -  2.5; 
ITEM  JJ  F,R  24  -  CC  +  .3; 

IF  RR  >  .3;  ... 

Note  that  if  II  is  an  integer  item, 
<real-literal>  cannot  be  implicitly 


"equivalent  to  presetting 
with  (*F  24*)  (-0.1)" 

"-0.1  is  rounded  to  a  24  bit 
mantissa" 

"-0.1  is  truncated  toward  minus 
infinity" 

".3  is  converted  to  CC's  type" 

”.3  is  rounded  to  a  24  bit  mantissa" 

then  II  -  2.5  is  illegal,  since  a 
converted  to .an  integer  value. 


8.3.2  BIT  LITERALS 
Syntax: 


<bit-literal> 

<bead-size>  B 

'  <bead> . . . 

<bead-slze> 

: 1  I  2 

1  3  I 

4  I  5 

<bead> 

:  :■  <dlgit> 

1  A  I 

B  |  C 

1  D  |  E  I 

F 

1  G  | 

H  I  I 

1  J  1  K  | 

L 

1  M  | 

N  |  0 

1  P  !  Q  1 

R 
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I  S  |  T  1  U  |  V 

Semantic!: 

A  <bit-literai>  represents  a  bit  string  value.  A  <bit-literal>  is 
composed  of  a  string  of  <beads>  whose  <bead-size>  in  bits  is  Indicated 
in  the  .  specification  of  the  literal.  The  total  size  of  the 
<bit-literal>  is  the  <bead-size>  times  the  number  of  beads  enclosed 
within  the  primes* 

The  <bead8>  of  a  <bit-literal>  can  be  specified  as  one  to  five  bits 
in  size.  The  <diglt>  preceding  the  B  indicates  the  <bead-size>.  Only 
those  <beads>  whose  value  will  fit  in  the  <bead-size>  indicated  are 
permitted.  The  digits  0-9  represent  their  actual  values;  the  letters 
A  -  V  represent  the  values  10  -  31  (see  Table  8-1). 
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Table  8-1.  Bit-Literal  Bead  Values 


1 

1 

1 

1 

Bead 

Minimum 

Bead 

Size 

1 

|  Binary 
|  Value 

1 

i 

i 

i 

i 

i 

i 

i 

i 

Bead 

Minimum 

Bead 

Size 

1 

|  Binary 
|  Value 

1 

1 

1 

0 

1 

1 

1  o 

i 

i 

i 

i 

G 

5 

1 

I  10000 

1 

1 

1 

1 

1 

|  1 

i 

i 

i 

i 

H 

5 

1 

1  10001 

1 

1 

1 

2 

2 

1 

1  10 

i 

i 

1 

1 

I 

5 

I 

1  10010 

1 

1 

3 

2 

1 

1  U 

i 

i 

i 

i 

J 

5 

1  10011 

1 

1 

4 

3 

1 

|  100 

i 

i 

i 

i 

K 

5 

1 

1  10100 

1 

1 

1 

5 

3 

1 

I  101 

i 

i 

i 

i 

L 

5 

I  10101 

1 

1 

1 

6 

3 

1 

I  110 

i 

i 

i 

i 

M 

5 

1  10110 

1 

1 

1 

7 

3 

1  111 

i 

i 

1 

1 

N 

5 

1  10111 

1 

1 

1 

8 

4 

1 

|  1000 

1 

1 

1 

1 

0 

5 

1  11000 

1 

1 

9 

4 

1 

I  1001 

i 

i 

1 

1 

P 

5 

1  11001 

1 

1 

1 

A 

4 

1 

I  1010 

1 

1 

1 

1 

Q 

5 

1  11010 

1 

! 

1 

B 

4 

I  1011 

1 

I 

! 

i 

R 

5 

1  11011 

1 

1 

1 

C 

4 

1 

1  1100 

i 

i 

1 

1 

S 

5 

1  11100 

1 

1 

1 

D 

4 

1 

1  1101 

1 

I 

1 

1 

1 

T 

5 

1  11101 

1 

1 

1 

E 

4 

1 

I  1110 

l 

i 

1 

i 

U 

5 

1  11110 

1 

1 

1 

1 

F 

4 

1 

t  mi 
i 

i 

i 

i 

i 

i 

i 

V 

5 

i  inn 

i 

« 
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8.3.3  BOOLEAN  LITERALS 


Syntax: 

<boolean-llteral> 


Semantics : 


: TRUE 


FALSE 


<Boolean-literals>  represent  the  two  possible  truth  values. 
Is  equivalent  to  IB'1',  and  FALSE  is  equivalent  to  1B'0' . 


8.3.4  CHARACTER  LITERALS 


Syntax: 


<cha rac t er-1 1 1 e  ral> 


Semantics : 


'  <character>. ., 


(8.1) 


<Character-literals>  denote  strings  of  character  values. 

<Character-llterals>  can  contain  any  <character>  (including  blank) 
that  Is  representable  In  an  implementation.  A  prime  character  (')  is 
represented  within  a  <character-literal>  by  two  consecutive  primes.  The 
size  of  a  <character-literal>  in  bytes  is  the  number  of  characters 
represented  within  the  containing  primes  (two  consecutive  primes 
represent  one  character) .  The  encoding  of  characters  is 
implementation-dependent . 


8.3.5  POINTER  LITERAL 


Syntax: 

<poiater-literal> 


: NULL 


Semantics : 


Any  pointer  item,  regardless  of  its  attribute,  can  have  the  value 
NULL,  which  indicates  that  the  item  points  to  no  ooject. 
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8.4  COMMENTS 
Syntax: 

(8.1) 
(8.1) 

Semantics: 


<comment> 


:■  ”  [<character>. . .]  " 

i  Z  [ <character> . . .]  Z 


A  <comment>  has  no  semantic  effect. 

A  <comment>  in  a  <deflne-strlng>  or  <actual-define-parameter>  is 
interpreted  as  part  of  the  character  sequence  to  be  substituted  when  the 
<deflne~call>  is  expanded. 


A  <comment>  can  appear  between  any  two  <symbols>,  subject  to  the 
constraints  below. 

Constraints : 


A  <comment>  delimited  by  a  quotation  mark  (")  is  not  permitted 
between  a  <def ine-name>  and  a  <def ine-string>  in  a  <def ine-declaration> , 
or  within  the  <actual-parameter-list>  in  a  <def ine-call>. 

A  <comment>  delimited  by  a  quotation  mark  cannot  contain  a 
quotation  mark,  and  a  <comment>  delimited  by  a  percent  character  (Z) 
cannot  contain  a  percent  character. 


8.S  BLANKS 

One  or  more  blanks  can  be  placed  between  <symbols>.  Blanks 
occurring  between  <symbols>  have  no  semantic  meaning. 

Constraints: 


Blanks  cannot  appear  within  <symbols>  except  in  Character- 
literals^  <define-strings> ,  <def ine-calls> ,  and  <comments>. 

One  or  more  blanks  must  appear  between  any  two  <symbols>  if  the 
absence  of  blanks  could  cause  them  to  be  interpreted  as  a  single  legal 
<symbol>,  except  that  whether  (*  represents  one  or  two  <symbols>  is 
contextually  determined,  e.g.,  (*  represents  two  symbols  in  the 

following  contexts: 

TABLE  AA  (*)  ...; 

ITEM  ...  POS  (*,  0); 


— 
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9.0  DIRECTIVES 

Syntax: 

<dlrective> 

*  •  Bi 

<compool-directive> 

(9.1) 

1 

<copy-directive> 

(9.2.1) 

1 

<aklp-directive> 

(9.2.2) 

1 

<begln-dlrective> 

(9.2.2) 

1 

<end-directive> 

(9.2.2) 

1 

<linkage-directive> 

(9.3) 

1 

<trace-directive> 

(9.4) 

1 

<interference-directive> 

(9.5) 

<reducible-directive> 

(9.6) 

1 

<noli s t-dl r ec t ive> 

(9.7.1) 

1 

<list-directive> 

(9.7.1) 

1 

<eject-directive> 

(9.7.1) 

1 

<listinv-directive> 

(9.7.2) 

1 

<listexp-dlrective> 

(9.7.2) 

1 

<listboth-directive> 

(9.7.2) 

1 

<base-directlve> 

(9.8) 

1 

<isbase-directive> 

(9.8) 

1 

<drop-directive> 

(9.8) 

1 

<lef tright-directive> 

(9.9) 

1 

<rearrange-directive> 

(9.9) 

I 

<initialize-directive> 

(9.10) 

1 

<order-directiv«> 

(9.11) 
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Semantics: 


<Directlves>  are  used  to  provide  supplemental  information  to  a 
compiler  about  the  <complete-program>,  and  to  provide  compiler  control. 

Each  implementation  can  specify  <directlves>  in  addition  to  those 
described  here,  but  each  must  conform  to  the  general  form  for  a 
<directive>.  <Directives>  begin  with  an  exclamation  point  and  terminate 
with  a  semicolon,  and  the  word  following  the  exclamation  point  must  not 
duplicate  that’ of  any  language-defined  directive. 


9.1  C0MP00L  DIRECTIVES 


Syntax: 

<compool-directive> 

<compool-directive-list> 


<compool-declared-name> 

<compool-file-name> 
Semantics : 

A  <compool-directive> 
module . 


:-  ! C0MP00L 

[<compool-directive-list>]  ; 

:*  [<compool-file-name>] 

<compool-declared-name> , . . . 

I  (  [<compool-file-name>J  ) 

:•  <name>  (8.2.1) 

|  (  <name>  )  (8.2.1) 

:■  <character-literal>  (8.3.4) 

is  used  to  access  definitions  in  a  compool 


A  <compool-file-name>  is  an  implementation-dependent  file  name  that 
specifies  the  desired  compool.  If  it  is  omitted,  an  implicit  unnamed 
compool  is  assumed.  A  <compool-f ile-name>  enclosed  in  parentheses 
implies  that  all  <names>  in  the  compool  are  to  be  made  available.  (This 
does  not  include  <names>  used  in  the  compool  that  were  obtained  from 
other  compools.) 

If  the  <corapool-directive>  contains  a  list  of  <compool-declared- 
names>,  only  those  names  (except  as  noted  below)  will  be  made  available. 

If  a  <compool-declared-name>  is  the  name  of  an  item,  table,  or 
block  declared  with  a  <type-name>,  that  <type-name>  is  also  made 
available  if  it  is  declared  in  that  compool.  (For  pointer  items,  this 
includes  the  name  of  the  pointed-to-type) .  If  a 
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<compool-declared-name>  Is  a  <table-item-name>,  cha  name  of  the  cable  in 
which  1C  Is  contained  Is  also  made  available.  Zf  a  cable  name  is  made 
available,  any  <status-llsts>  and  <status-type-names>  associated  with 
its  <dimenslons>  are  also  made  available,  provided  they  are  declared  in 
the  designated  compool. 

If  a  <com pool-dec la red-name>  is  Che  name  of  a  .table  or  block  and  is 
parenthesized,  all  names  declared  in  the  Cable  or  block  will  be  made 
available,  as  well  as  all  type  names  referenced  in  the  table  or  block, 
provided  they  are  declared  in  the  designated  compool.  If  a 
<compool-declared-name>  is  a  <table-type-name>  or  <block-type-name>,  the 
names  of  these  components  will  be  made  available  whether  or  not  the  name 
is  parenthesized. 

If  a  status  item  name  is  made  available,  its  associated 
<status-list>  and  <scatus-type*»name>  (if  any)  will  also  be  made 
available,  if  they  were  declared  in  the  designated  compool. 

If  a  <compool-declared-name>  is  the  name  of  a  subroutine,  any 
<type-names>  associated  with  that  subroutine's  formal  parameters  and 
return  value  will  also  be  made  available,  if  they  are  declared  in  the 
designated  compool. 

Constraints; 

A  <compool-directive>  must  only  occur  immediately  after  START  or 
immediately  following  another  <compool-directive> . 

The  <compool-declared-naaes>  must  have  been  declared  in  the 
designated  compool. 

A  <compool-declared-name>  cannot  be  the  name  of  a  component 
declared  in  a  type  declaration,  nor  can  it  be  the  name  of  a  formal 
parameter  of  a  subroutine. 

9.2  TEXT  DIRECTIVES 
9.2.1  COPY  DIRECTIVES 
Syntax: 

<copy-directive>  fCOPY 

<character-literal>  ;  (8.3.4) 
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Semantics: 

The  <copy-dlrective>  is  used  co  copy  che  concents  of  a  text  file 
into  a  prograa.  The  <copy-directive>  can  be  viewed  as  a  <define-call>; 
it  is  expanded  at  the  point  of  its  occurrence  by  substituting  the 
entirety  of  the  file  being  copied.  The  <character-literal>  is  an 
implementation-dependent  file  name. 


9.2.£  SKI?,  BEGIN,  AND  END  DIRECTIVES 


Syntax: 

<skip-directive> 

: :»  ! SKIP 

[<letter>]  ; 

(8.1) 

<begin-directive> 

:  s-  ! BEGIN 

[<letter>J  ; 

(8.1) 

<end-di rect ive> 

: :■  ! END  ; 

Semantics : 

The  <skip-directive> 

is  used 

in  conjunction 

with 

<begin-directive>  and  an  <end-direetlve>  to  cause  text  enclosed  in  the 
latter  two  to  be  ignored  in  Che  process  of  compilation. 

A  <skip-directive>  with  a  <letter>  will  suppress  the  processing  of 
all  text  following  a  <begin-directive>  containing  the  same  <letter>  up 
to  the  matching  <end-directive>.  A  <sklp-directive>  with  no  <letter> 
refers  to  all  <begln-directives>.  The  text  following  a  <begin- 
directive>  with  no  <letter>  can  be  suppressed  only  by  a  <skip- 
directive>  with  no  <letter>. 

Begln-end  directive  pairs  can  be  nested.  Within  a  begin-end 
directive  set  whose  text  is  being  suppressed,  enclosed  <begin- 
directives>  are  recognized  for  the  purpose  of  matching  <end-directives>. 

Within  a  begin-end  directive  pair  whose  text  is  being  suppressed, 
<copy-dlrectives>  and  <deflne-calls>  will  not  be  expanded. 


9.3  LINKAGE  DIRECTIVES 
Syntax: 

<linkage-directive>  ILINKAGE 

<symbol>...  ;  (8.2) 
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Semantics : 


The  <llnkage-dlrectlve>  indicates  that  the  specified  subroutine 
does  not  obey  standard  J73  linkage  conventions.  The  <symbol>  string 
specifies  the  implementation-dependent  linkage  type  to  be  used  in 
linking  the  procedure. 

Constraints: 

The  <linkage-dlrective>  must  only  occur  in  a  <subroutine- 
declaration>  or  <subroutine-definitlon>  between  the  heading  and  the 
<declarations>  of  the  formal  parameters. 

If  a  < subrout ine-def ini tion>  contains  a  <linkage-directive>,  every 
<subroutine-declaration>  for  that  subroutine  must  contain  the  same 
<linkage-directive> . 

9.4  TRACE  DIRECTIVES 
Syntax: 

<  t race-d i rec  t i ve> 


<trace-control> 

Semantics : 

The  <trace-directive>  provides  a  run-time  facility  to  trace  program 
flow  and  to  monitor  data  assignment.  This  "tracing"  will  be  active  from 
the  lexical  point  at  which  the  <trace-directive>  occurs  in  the  source 
until  the  end  of  the  scope  containing  the  directive.  Its  effect  extends 
into  nested  procedures  declared  within  this  lexical  range  of  statements. 

The  <names>  in  the  <trace-directive>  are  the  names  that  will  be 
traced,  l.e.,  certain  uses  of  these  names  as  described  in  the  following 
sentences  will  be  noted  in  an  implementation-dependent  manner,  for 
example  on  a  symbolic  output  file.  For  statement  names,  tracing  of  the 
associated  statement  will  be  noted  each  time  the  statement  is  fallen 
into  or  branched  to.  For  data  names,  modification  of  the  data  object 
and  its  new  value  will  be  noted.  Modification  of  a  data  object  is 
considered  to  have  occurred  upon  execution  of  an  assignment  statement  in 
which  the  data  object  is  the  target  or  upon  return  from  a  subroutine  to 
which  the  data  object  was  passed  as  an  actual  output  parameter.  For 
tables,  modification  of  the  entire  table,  a  table  entry,  or  an  item  in 
the  table  will  be  noted.  For  blocks,  modification  of  any  data  contained 
in  the  block  will  be  noted.  For  subroutine  names,  each  call  to  the 


::-  ! TRACE 

[<trace-control>] 

<name> , . . .  ; 

::•  (  <boolean-formula>  )  (5.2.2) 
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subroutine  will  be  noted.  If  the  subroutine  containing  the 
<trace-dlrective>  is  named  in  the  directive  and  the  directive  is  placed 
immediately  after  the  <procedure  heading>  or  <f unction  headlng>,  entry 
and  exit  to  that  subroutine  will  be  noted. 

If  a  <trace-control>  appears  in  the  <trace-directive>,  the 
<trace-control>  formula  will  be  tested  dynamically  at  each  use  of  a 
<naae>  as  defined  in  the  preceding  paragraph.  The  trace  output  is 
suppressed  if  the  formula  is  determined  to  be  false.  If  the 
<traee-control>  is  omitted,  it  is  considered  to  be  true. 

If  two  or  more  active  <trace-directlves>  contain  the  same  <name>, 
then  the  lexically  latest  one  overrides  the  earlier  ones  for  that 
<name>. 

Constraints; 

All  <names>  in  the  <trace-directive>,  including  names  used  in  the 
<trace-control>,  except  for  statement  names  and  subroutine  names,  must 
have  been  declared  prior  to  their  use  in  the  <trace-directive>. 

A  <trace-directive>  can  occur  only  within  a  <statement>. 

A  <bit-formula>  cannot  be  implicitly  converted  to  the 
<boolean-formula>  in  a  <trace-control>. 


9.5  INTERFERENCE  DIRECTIVES 
Syntax: 

<interference-directive>  : :«  ! INTERFERENCE 

<interference-control>  ; 

<interference-control>  : <data-name>  ;  (2.6) 

<data-name> , . . .  (2.6) 

Semantics: 

The  <interf erence-directlve>  informs  the  compiler  that  it  cannot 
assume  that  the  storage  associated  with  the  name  to  the  left  of  the 
colon  is  distinct  from  the  storage  associated  with  the  names  to  the 
right  of  the  colon.  In  the  absence  of  an  <interference-directive>  the 
compiler  can  make  optimizations  on  the  assumption  that  distinct 
<data-names>  refer  to  distinct  storage  locations.  If  two  <data-names> 
refer  to  the  same  storage  location,  these  optimizations  could  result  in 
erroneous  code.  If  two  <data-names>  share  the  same  storage,  an 
assignment  to  one  name  should  affect  the  value  of  the  other.  If  the 
compiler  optimizes  on  the  assumption  of  non-interference,  these 
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semantics  might  not  be  preserved. 

The  compiler  is  aware  of  storage  overlapping  as  a  result  of 
<specifled-table-items>  and  as  a  result  of  the  arrangement  of  data 
within  a  single  overlay.  This  overlapping  need  not  be  reported  via  an 
<interference-directive>.  Other  instances  of  overlap,  e.g.,  as  a  result 
of  absolute  addresses  in  separate  overlays,  must  be  stated  by  the  use  of 
an  <lnterference-directive>. 

An  <interference-directlve>  can  occur  only  in  a  <declaration>. 

All  <data-names>  in  the  <lnterference-control>  must  have  been 
declared  prior  to  their  use  in  the  <lnterference-directlve>. 


9.6  REDUCIBLE  DIRECTIVES 
Syntax: 

<reduclble-directive>  {REDUCIBLE  ; 

Semantics: 


The  <reducible-directlve>  is  used  to  allow  additional  optimization 
of  function-calls.  A  reducible  function  is  one  for  which  all  calls  with 
identically-valued  actual  parameters  result  in  identical  function  values 
and  output  parameter  values,  and  which  does  not  modify  any  data  except 
actual  output  parameters  and  automatic  data  declared  within  its  own 
body.  If  a  <reducible-dlrective>  is  used  to  designate  such  functions  as 
reducible,  the  compiler  may  detect  the  existence  of  such  common  calls, 
save  the  values  returned  from  the  initial  call  for  use  in  place  of  any 
subsequent  calls,  and  delete  these  subsequent  calls. 

Constraints: 

The  <reducible-directive>,  if  present,  must  be  placed  immediately 
following  the  semicolon  of  the  <function-heading>. 

If  a  function  designated  as  reducible  is  both  declared  and  defined, 
the  <reduclble-dlrective>  must  appear  in  both  the  definition  of  the 
function  and  in  all  declarations  of  it. 


9.7  LISTING  DIRECTIVES 


9.7.1  SOURCE-LISTING  DIRECTIVES 
Syntax: 
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<nolist-directlve> 

<li8t-directive> 

<eject-directive> 

Semantics: 


! NOLIST  ; 
(LIST  ; 
::-  ! EJECT  ; 


Listing  directives  are  used  to  provide  source  listing  control 
information  to  the  compiler.’  The  <nolist-directive>  causes  suppression 
of  the  source  listing  beginning  with  the  next  source  line,  up  to  and 
Including  the  next  <list-directive> ,  which  causes  the  listing  to  be 
resumed . 

The  <eject-directive>  causes  a  page  eject  of  the  source  listing 
before  listing  the  following  source  lines.  The  <eject-directive>  is 
ignored  if  the  source  listing  is  suppressed. 


9.7.2  DEFINE-LISTING  DIRECTIVES 
Syntax: 

::=■  iLISTINV  ; 
JLISTEXP  ; 
!LISTBOTH  ; 

Semantics: 


<listinv-directive> 

<llstexp-directlve> 

<listboth-directive> 


Define-listing  directives  allow  programmer  control  over  the  text  to 
be  included  in  the  source  program  listing  for  <def ine-calls> . 

The  text  contained  in  the  listing  for  a  particular  <def ine-call> 
depends  on  the  define-listing  directive  which  was  in  effect  at  the  point 
of  the  corresponding  <def ine-declaratlon>  (not  on  the  directive  in 
effect  at  the  point  of  the  <def ine-call>) .  If  this  directive  was 
ILISTINV,  then  the  listing  contains  the  text  of  the  <define-call>;  if 
the  directive  was  ILISTEXP,  then  the  listing  contains  the  expanded 
string  (the  <def ine-string>  after  substitution  of 
<actual-define-parameters>) ;  if  the  directive  was  ILXSTBOTH,  then  the 
listing  contains  both  the  invocation  and  the  expansion. 

Each  define-listing  directive  is  in  effect  from  the  lexical  point 
at  which  it  appears  to  the  end  of  the  current  scope  or  to  the  point  at 
which  the  next  define-listing  directive  appears,  whichever  is  first. 
The  default  define-listing  directive  in  effect  at  the  beginning  of  every 
module  is  !LISTINV. 
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Constraint; 

<Listinv-directives>,  <listexp-directives>  and 

<listboth-dlrectives>  may  appear  only  In  a  <declaration> . 

Note: 


The  effect  of  a  define-listing  directive  for  a  particular 
<define-call>  is  Independent  of  whether  a  <nolist-directive>  is 
suppressing  the  source  listing  at  the  point  of  the  <define-dedaration> 
being  invoked. 


9.8  REGISTER  DIRECTIVES 


Syntax: 


<base-directive> 

! BASE  <data-name> 

(2.6) 

<integer-literal>  ; 

(8.3.1) 

< i sba se-d i r ec t I ve> 

:  :•  ! ISBASE  <data-name> 

(2.6) 

<integer-literal>  ; 

(8.3.1) 

<drop-directive> 

: :«  ! DROP 

<integer-literal>  ; 

(8.3.1) 

Semantics : 

Register  directives  affect  target-machine  register  allocation. 
Each  of  these  three  directives  uses  an  <integer-literal>  in  a 
target-machine-dependent  way  to  specify  which  register  is  affected. 

The  <base-di rec tive>  loads  the  specified  register  with  the  address 
of  the  object  corresponding  to  the  <data-name>. 

The  <isbase-directive>  directs  the  compiler  to  assume  that  the 
specified  register  contains  the  address  of  the  data  object  corresponding 
to  the  <data-name> ,  but  to  take  no  action  to  guarantee  it. 

The  <drop-directive>  frees  the  specified  register  for  other  use  by 
the  compiler  in  generating  code  for  subsequent  statements.  Both  !BA5E 
and  ! ISBASE  cause  the  compiler  to  dedicate  the  register  to  the  value  it 
currently  contains  until  !DR0P  or  the  end  of  the  current  scope  is 
encountered . 

Register  directives  may  be  ignored  in  implementations  for  machines 
on  which  register  allocation  is  not  meaningful. 


MIL-STD-1589B  (USAF) 
06  June  1980 


9.9  EXPRESSION  EVALUATION  ORDER  DIRECTIVES 
Syntax; 

<lef tright-directive> 

<  r e  a  rr ange-d i rec  t i ve> 

Semantics : 

If  a  <lef tright-directive>  is  in  effect,  operators  at  the  same 
precedence  level  are  evaluated  in  left-to-right  order  within  a  given 
<formula> ,  consistent  with  the  order  imposed  by  parentheses. 

If  a  <rearrange-directive>  is  in  effect,  order  of  evaluation  is 
still  constrained  by  parentheses  and  operator  precedence,  but  the 
compiler  is  otherwise  free  to  rearrange  the  expression  for  more  optimal 
code  generation,  such  as  by  applying  associative  and  commutative  laws. 

The  effect  of  each  of  these  directives  extends  from  the  point  at 
which  it  apoears  to  the  end  of  the  current  namescope  or  to  the  point  at 
which  a  different  expresslon-evaluatlon-order  directive  appears, 
whichever  is  first.  At  the  beginning  of  each  module,  a  <rearrange- 
dlrective>  is  in  effect  by  default. 


!  LEFTRIGHT  ; 
: ! REARRANGE  ; 


9.10  INITIALIZATION  DIRECTIVES 
Syntax; 

<initialize-directive>  : UNITIALIZE  ; 

Semantics : 


The  <lnltiallze-directive>  causes  all  STATIC  data  objects  that  are 
not  explicitly  initialized  via  an  <item-preset> ,  <table-preset> ,  or 
<block-preset> ,  to  be  preset  by  default  to  all  zero  bits. 

Its  effect  extends  from  the  point  at  which  it  appears  to  the  end  of 
the  current  namescope. 

Constraint; 

The  <initialize-directive>  may  appear  only  in  <declarations>,  but 
not  in  a  < table-bod y>  nor  in  a  <block-body-part>  nor  in  a 
<subroutine-declaratlon> . 
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9.11  ALLOCATION  ORDER  DIRECTIVES 
Syntax: 

<order-directive>  : ! ORDER  ; 

Semantics: 

The  <order-directive>  directs  a  compiler  to  allocate  storage  for 
the  data  objects  in  a  block  or  ordinary  table  in  the  order  in  which 
their  declarations  appear  in  the  text  of  the  <block-body-part>  or  the 
<ordinary-table-options> .  Lexically  declared  data  objects  that  occur 
earlier  in  text  are  allocated  physically  lower  addresses,  and  if  data 
objects  share  a  word,  lexically  earlier  data  are  allocated  to  the  left 
of  later  data.  In  the  absence  of  an  <order-directive>,  a  compiler  is 
free  to  rearrange  the  physical  storage  layout  for  ease  of  access  or  more 
optimal  utilization  of  memory. 

The  effect  of  the  <order-directive>  extends  from  the  point  at  which 
it  appears  to  the  end  of  the  current  block  or  table.  If  the 
<order-directlve>  is  in  a  block,  its  effect  extends  to  the  components  of 
any  blocks  or  ordinary  tables  contained  in  the  block. 

If  an  <order-directive>  appears  in  an  <ordinary“table-options>  in  a 
<table-type-declaration>,  the  ordering  extends  to  all  tables  declared  of 
chat  type. 

Constraints : 


A  block  affected 
<overlay-declaratlon> . 

by 

an  <order-directive> 

cannot 

contain 

an 

The  <order-directive>. 

if  present,  must  be 

the 

first 

of 

the 

<block-body-options>  in 

the 

<block-body-part>,  or 

the 

first 

of 

the 

<ordinary-table-options>  in  the  <ordinary-table-body>. 
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APPENDIX 

CROSS** REFERENCE  INDEX 

This  appendix  provides  a  cross-reference  for  terminal  and 
non-terminal  constructs  in  the  J73  syntax  used  in  this  manual.  For  each 
construct ,  columns  give  the  section  in  the  manual  where  it  is  defined 
and  the  sections  where  it  is  used  or  referenced. 


Construct 

Definition 

References 

A 

2. 1.1.3,  7.0,  8.1, 

ABORT 

4.5,  4.10,  8.2.2 

abort-phrase 

4.5 

4.5 

abort-statement 

4.10 

4,0 

ABS 

6.3.6,  8.2.2 

abs-function 

6.3.6 

6.3 

absolute-address 

2.6 

2.6 

actual-deflne-parameter 

2.4.1 

2.4.1 

actual-define-parameter-llst 

2.4.1 

2.4.1 

actual-input-parameter 

4.5 

4.5 

actual-output-parameter 

4.5 

4.5 

actual-parameter-list 

4.5 

4.5,  6.3 

allocation-specifier 

2.1.5 

2.1.1,  2.1.2,  2.1.4 

AND 

5.2.1,  8.2.2,  8.2.3 

and-continuation 

5.2 

5.2 

arithmetic-operator 

8.2.3 

8.2.3 

assignment-operator 

8.2.3 

8.2.3 

assignment-statement 

4.1 

4.0 
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Construct 

Definition 

References 

B 

2. 1.1.4,  7.0,  8.1, 

8.3.2 

bas£ 

9.8 

base-directive 

9.8 

9.0 

bead 

8.3.2 

8.3.2 

bead-size 

8.3.2 

8.3.2 

BEGIN 

1.2.3,  2.0,  2.1.2 

2. 1.2.4,  2.1.4,  2 
2.5.2,  2.7,  3.1,  « 

4.4,  8.2.2,  9.2.2 

begin-directive 

9.2.1 

9.0 

BIT 

6.1,  8.2.2 

bit-conversion 

7.0 

5.2 

bit-formula 

5.2 

4.4,  5.0,  5.2, 
5.2.2,  6.3.3, 
6.3.5 

bit-function 

6.3.3 

6.3 

bit-function-call 

5.2 

5.2 

bit-function-variable 

6.1 

6.1 

bit-item-description 

2. 1.1. 4 

2. 1.1.4 

bit-literal 

8.3.2 

5.2,  8.3 

bit-operator 

8.2.3 

8.2.3 

bit-primary 

5.2 

5.2,  5.2.1 

BITSINBYTE 

1.4 
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Construct 

Definition 

References 

BITSINPO INTER 

1.4 

BITSINWORD 

1.4 

BITSIZE 

6.3.8,  8.2.2 

bit-size 

't 

e 

e 

e 

CM 

2. 1.1.4 

bits-per— entry 

2. 1.2. 2 

2. 1.2.2 

bit-type-conversion 

7.0 

7.0 

bi t-type-de  scr ip  tion 

2. 1.1.4 

2.1.1,  7.0 

bit-type— name 

2. 1.1.4 

2. 1.1.4,  7.0 

bit-variable 

5.2 

5.2,  6.1 

BLOCK 

2.1.4,  2.2,  2.5.1, 
8.2.2 

block-body-options 

2.1.4 

2.1.4 

block-body-part 

2.1.4 

2.1.4,  2.2 

block-declaration 

2.1.4 

2.1 

block-dereference 

6.1 

4.5,  6.1,  6.3.1 

block-item 

6.1 

6.1 

block-name 

2.1.4 

2.1.4,  2.5.1,  2.6, 
5,  6.3.1,  6.3.8 

block-preset 

2.1.6 

2.1.4 

block-preset-list 

2.1.6 

2.1.6 

block-preset-values-option 

2.1.6 

2.1.6 

block- table 

6.1 

6.1 

block-table-entry 

6.1 

6.1 

block-table-item 


6.1 


6.1 
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References 

block-type-declaration 

2.2 

2.2 

block- type-name 

2.2 

2. 1.1.7,  2.1.4,  2.2 

i 

boolean-formula 

S.2.2 

4.2,  4.3,  9.4 

boolean-li teral 

8.3.3 

5.2,  8.3 

bo unds-f unction 

6.3.9 

6.3 

BY 

• 

4.2,  8.2.2 

by- formula 

4.2 

4.2 

by-or- then- phrase 

4.2 

4.2 

byphra se 

i 

4.2 

4.2 

1  BYREF 

3.3,  8.2.2 

BYRES 

3.3,  8.2.2 

BYTE 

6.1,  6.3.4,  8.2.2 

byte-function 

6.3.4 

6.3 

A 

<|  byte-function-variable 

6.1 

6.1 

n  BYTEPOS 

1.4 

BYTESINWORD 

1 

alternative 

4.4 

4.4 

1 

| 
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References 


esse- body 

4.4 

4.4 

case-index 

4.4 

4.4 

case-index-group 

4.4 

4.4 

csse-seleetor-f  omuls 

4.4 

4.4 

case-statement 

4.4 

4.0 

character 

8.1 

2.4,  2.4 

8.4 

character-conversion 

7.0 

5.3 

character-f  omuls 

5.3 

4.4,  5.0 

5.3,  6.3 

character-f unction-call 

5.3 

5.3 

charac ter- item-description 

2. 1.1.5 

2. 1.1.5 

character-literal 

8.3.4 

8.3,  9.1 

character-size 

2. 1.1.5 

2. 1.1.5 

character-type-description 

2. 1.1. 5 

2.1.1,  7 

character-type-name 

2. 1.1. 5 

2. 1.1.5, 

character-variable 

5.3 

5.3,  6.1 

comment 

8.4 

8.2 

complle-tlme-bit-f  omuls 

5.1.2 

4.4,  5.0 

complle-time-character-fomula 

5.1.3 

4.4,  5.0 

compile- 1  ime—  f  ixed-  f  o  mula 

5.1.3 

5.1 

compile- time-floating-f  omuls 

5.1.2 

1.4,  5.1 

compile- time- formula 

5.0 

2.1.6 

compile-time-inte^er-foI2sS*^_ 
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References 

2. 1.1.3,  2. 1.1.4 
2. 1.1. 5,  2. 1.1.6 
2. 1.2.1,  2. 1.2.2, 

2. 1.2.4,  2.1.6,  : 

4.4,  5.1,  6.3.9 

compile- 1 ime-nuaeric- f o  rmula 

5.1 

5.0 

complle-tlme— pointer-formula 

5.5 

5.0 

coapUe-t  ime-status-  f  o  rmula 

5.4 

2. 1.2.1,  2.1.6, 
4.4,  5.0 

coaple  te-prog ran 

1.1 

coapound-def 

2.5.1 

2.5.1 

coapound-ref 

2.5.2 

2.5.2 

com pound-statement 

4.0 

4.0 

COMPOOL 

1.2.1,  8.2.2,  9.1 

coapool-dec la  ra  tlon 

2.0 

1.2.1,  2.0 

compool-declared-name 

9.1 

9.1 

coapool-dlrectlve 

9.1 

9.0 

compool-directive— list 

9.1 

9.1 

compool- file-name 

9.1 

o.l 

com pool-module 

1.2.1 

1.1 

c  otn  pool-name 

1.2.1 

1.2.1 

CONDITION 

8.2.2 

conditional-statement 

4.3 

4.3 

CONSTANT 

2.1.3,  8.2.2 

constant-declaration 

2.1.3 

2.0,  2.1 

6 
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Construct 

Definition 

References 

constant-index 

2.1.6 

2.1.6 

constant-1 tern-name 

2.1.3 

2.1 .3,  6.1 ,  6.2 

constant- table-item-name 

6.2 

6.2 

constant-table-name 

2.1.3 

2.1.3.  6.2 

continuation 

4.2 

4.2 

control-clause 

4.2 

4.2 

control-item 

4.2 

4.2 

control-letter 

4.2 

4.2.  6.2 

controlled-statement 

4.2 

4.2 

cont  rol-variable 

4.2 

4.2 

COPY 

9.2.1 

copy-directive 

9.2.1 

9.0 

D 

2. 1.2.3,  8.1,  8.3.2 

data-declaratlon 

2.1 

2.0,  2.1.4,  2.5.1, 
2.5.2 

data-name 

2.6 

2.6,  3.3,  9.5,  9.8 

declaration 

2.0 

1.2.2,  1.2.3,  2.0, 
3.1,  3.2 

DEF 

1.2.2,  2.5.1,  8.2.2 

DEFAULT 

4.4,  8.2.2 

default-option 

4.4 

4.4 

default-preset-sublist 

2.1.6 

2.1.6 

de  f  aul t-subl i s  t 

2. 1.1. 6 

2. 1.1. 6 
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def-bloclc-instantiation 

2.5.1 

2.5.1 

DEFINE 

2.4,  8.2.2 

def ine-call 

2.4.1 

8.2 

def ine-name 

2.4 

2.4,  2.4.1 

def ine-strlng 

2.4 

2.4,  8.2 

definition-part 

2.4 

2.4 

def ine-declaration 

2.4 

2.0 

def- specif lea tion 

2.5.1 

2.5 

def-speciflcatlon-cholce 

2.5.1 

2.5.1 

dereference 

6.1 

6.1 

digit 

8.1 

8.1,  8.2.1,  8.3.1, 
8.3.2 

de reference-operator 

8.2.3 

8.2.3 

dimension 

2. 1.2.1 

2. 1.2.1 

dimension— list 

2. 1.2.1 

2.1.2,  2.1.3,  2.2 

dimens ion— numbe  r 

6.3.9 

6.3.9 

directive 

9.0 

1.2.1,  1.2.2,  1.2.3 
2.0,  2. 1.2.3, 

2. 1.2. 4,  2.1.4, 

2.5.1,  2.5.2,  3.0, 

3.1,  3.2,  4.0, 

4.2,  4.4 

DROP 

9.8 

drop-directive 

9.8 

9.0 

E 

8.1,  8.3.2 
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References 

EJECT 

9.7.1 

9.7 

eject-directive 

9.7 

9.0 
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